RE: Small bug in caget

[<michael.abbott@diamond.ac.uk>]

From: Andrew Johnson [mailto:anj@aps.anl.gov]
> On 11/24/2014 02:48 AM, michael.abbott@diamond.ac.uk wrote:
> > Interesting.  I know I'd convinced myself some time ago that DBF_CHAR
> > was unsigned, but I guess that was by inspecting some code ... and it
> > looks as if different corners of EPICS do this differently.  Certainly
> > where I looked I found the following mappings:
> >
> > 	CHAR		8-bit unsigned
> > 	SHORT		16-bit signed
> > 	LONG		32-bit signed
> > 	ENUM		16-bit unsigned (plus the strings)
> > 	STRING	40 8-bit bytes (indeterminate sign? haven't checked)
> > 	FLOAT		32-bit floating point
> > 	DOUBLE	64-bit floating point
> >
> > That is, as I understand it, the complete list of transportable EPICS
> > CA datatypes.
> 
> That looks correct. The STRING representation uses the native char of
> the client's ABI, so the characters may be signed or unsigned.

In that case I don't understand why you're not 100% convinced that treating CA CHAR values as signed is a bug.  Even if the innards of the IOC are confused about this, caget can only work with values that Channel Access provides it ... so it should obey the rules of Channel Access.

> Inside the IOC database we use a wider set of types and different (and
> incompatible) definitions for the field index enum values DBF_STRING,
> DBF_CHAR etc.

I really don't understand why this is, but I guess it's historical.  I understand that the IOC has extra concepts (database links, for example), but why and how it can support data that's not transportable over CA really makes no sense to me.

However, I'm sure this is a can of worms with decades of history that I really don't want to open!

> The CA client data types are defined in db_access.h, while the IOC's
> types are in dbFldTypes.h. I don't have time to explain the history of
> this split right now...

Let's not go there.

-- 
This e-mail and any attachments may contain confidential, copyright and or privileged material, and are for the use of the intended addressee only. If you are not the intended addressee or an authorised recipient of the addressee please notify us of receipt by returning the e-mail and do not use, copy, retain, distribute or disclose the information in or attached to the e-mail.
Any opinions expressed within this e-mail are those of the individual and not necessarily of Diamond Light Source Ltd. 
Diamond Light Source Ltd. cannot guarantee that this e-mail or any attachments are free from viruses and we cannot accept liability for any damage which you may sustain as a result of software viruses which may be transmitted in or with the message.
Diamond Light Source Limited (company no. 4375679). Registered in England and Wales with its registered office at Diamond House, Harwell Science and Innovation Campus, Didcot, Oxfordshire, OX11 0DE, United Kingdom