Experimental Physics and
Industrial Control System

<[email protected]> · Mon, 24 Nov 2014 08:48:40 +0000

Hi Andrew,

> From: Andrew Johnson [mailto:[email protected]]
> Sent: 21 November 2014 18:23
> To: Abbott, Michael (DLSLtd,RAL,TEC); [email protected]
> Subject: Re: Small bug in caget
> 
> 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.

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.  However it sounds as if things aren't as well defined as I thought.

Is it worth digging deeper into the definitions of these types?  I don't remember where I got the list above, but my understanding was that it was definitive ... but you're saying that things are not so clear.

> 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. 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.
> 
> I will be introducing two 64-bit integer field types into the IOC
> database on the 3.16 branch which will require changes to some external
> software (the new DBF_INT64 and DBF_UINT64 values appear in the middle
> of the enum dbfType range, they can't be appended to it). I could take
> that opportunity to try fixing some of these other type issues as well
> if the community wants that and is willing to accept more breakage.
>
> This work would not affect CA clients though, I am not going to be
> touching that protocol or the db_access.h types which are used by
> clients.

If you're not changing CA how do you propose to transport 64-bit integers?  Without CA support I don't think I understand your proposal.

-- 
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

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System