Experimental Physics and
Industrial Control System

Benjamin Franksen <[email protected]> · Sat, 22 Nov 2014 15:15:26 +0100

Am Freitag, 21. November 2014, 12:23:16 schrieb Andrew Johnson:
> Hi Michael,
>
> On 11/20/2014 05:48 AM, [email protected] wrote:
> > I've just noticed that caget incorrectly prints values of type
> > DBR_CHAR, or to be precise, the behaviour of caget depends on whether
> > the compiler is operating with signed or unsigned characters.
>
> This is actually the case within the IOC as well, a DBF_CHAR field (and
> the epicsInt8 C type) may be signed or unsigned depending on the ABI of
> the IOC's target architecture. I'm thus not 100% convinced whether this
> is actually a bug or not.
>
> I was slightly surprised to see that the dbr_char_t is explicitly
> defined in db_access.h to be unsigned (it's a typedef for epicsUInt8),
> since dbr_short_t and dbr_long_t are both signed types. However for
> historical reasons many of our types are a bit messed up anyway, for
> example a dbr_int_t is a 16-bit quantity, reflecting the processor
> standards at the time when this code was created.
>
> I have looked at cleaning this kind of thing up inside the IOC at least,
> but it's not easy since compilers don't like passing pointers to
> unsigned char into functions such as strlen() that expect unqualified
> char pointers.

It is notable how pedantic C compilers can be for perfectly harmless re-
interpretations via pointer casting such as in in this case, where the
compiler *knows* that the underlying types have the same representation. The
compiler warning suggests that it would be better to add a type cast, which we
do and so get rid of the warning. Unfortunately this makes the code *worse*.
Because the type cast asserts that "the programmer knows what he does", so the
compiler never complains or warns again. If we later change the source type to
something that has a different representation, the code with the cast remains
"valid" when in fact it completely breaks the program now. Had the compiler
accepted the code with the implicit char* to unsigned char* pointer conversion
(because it can see that it is a safe conversion) it could now complain and
would save us from shooting ourselves in the foot.

> We should probably have separate DBF_CHAR and DBF_INT8
> field types to distinguish whether a field should be represented as a
> character or integer value, but we don't currently.

Slightly paraphrasing, DBF_CHAR would represent text, while DBF_INT8 and
DBF_UINT8 represent (8 bit) integer values. That means we make a /semantic/
distinction in the type, not just a representational one. I guess this was the
idea behind making char, signed char, and unsigned char three distinct types
in C. (The problem with this idea is of course that char should have >= 21
bits, representing a Unicode code point, not 8 bit. Which is the reason most
modern languages offer a dedicated string or text type that hides the internal
representation. We don't have the luxury to use such a language, so we have to
compromise.)

Cheers
Ben
--
"Make it so they have to reboot after every typo." -- Scott Adams

________________________________

Helmholtz-Zentrum Berlin für Materialien und Energie GmbH

Mitglied der Hermann von Helmholtz-Gemeinschaft Deutscher Forschungszentren e.V.

Aufsichtsrat: Vorsitzender Prof. Dr. Dr. h.c. mult. Joachim Treusch, stv. Vorsitzende Dr. Beatrix Vierkorn-Rudolph
Geschäftsführung: Prof. Dr. Anke Rita Kaysser-Pyzalla, Thomas Frederking

Sitz Berlin, AG Charlottenburg, 89 HRB 5583

Postadresse:
Hahn-Meitner-Platz 1
D-14109 Berlin

http://www.helmholtz-berlin.de

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System