Experimental Physics and
Industrial Control System

Benjamin Franksen <[email protected]> · Wed, 23 Feb 2005 13:15:11 +0100

Some comments regarding the signed/unsigned conversion issue:

On Wednesday 23 February 2005 04:29, Jeff Hill wrote:
> > From: Marty Kraimer [mailto:[email protected]]
> > >Jeff Hill wrote:
> > >o Data access supports safe conversion between all of the
> > >primitive types available in C. If the source is out of range
> >
> > for
> >
> > >the destination the operation is not performed and an error is
> > >returned to the user. This has already been implemented.
> >
> > Is this what we want?
> > Let me give an example
> >
> > An IOC has a field that is an unsigned 32 bit integer.
> > A java application asks for the fields as a signed 32 bit
> > integer. The java application only uses the field as a
> > bit mask.
> >
> > Should CA return an error if the value happens to have the high
> > order
> > bit = 1?
> > I say no.
>
> I say yes. No doubts from my perspective. How would the IOC know
> what the client is using the data for? This isn't close enough is
> good enough environment. We are coding a control system. We don't
> want intermittent failures that occur only when the data has
> certain magnitudes.
>
> If the bit field is an unsigned number and higher order bits are
> set then this would be a very high magnitude unsigned number. If
> this exceeds the magnitude of the signed type in the Java client,
> and if there is even the slightest possibility that any Java
> client might use the result as a signed number, and not as a bit
> field, then a disaster will eventually occur. A code that is
> sourcing out bit fields should be providing a way to specify the
> starting bit and the field length so that bit fields anywhere
> within a 32 bit unsigned number can be accessed, and the Java
> client upon encountering conversion problems could request the 32
> bit field as two 16 bit fields with complete safety and no loss
> of functionality.

Yes. Marty, in your proposal there is a data type to request in this 
case: an array[4] of octets. Octet is explicitly specified to be used 
in cases where the raw bit pattern is what is wanted, as opposed to an 
integral /number/.

A predictable (immediate) exception is definitely better than eventual 
failure when values go out of range.

Regarding the current use of unsigned types, there are three cases to 
consider:

(a) A raw value that gets written to or read from hardware and that is 
specified by the manufacturer to be an unsigned number.

(b) Any other integral number, that has a natural lower bound of zero.

(c) A bit field or enumeration.

I think the only real justification for using unsigned integral types is 
case (a).

In almost all cases of (b), we can use a signed type (if strictly 
necessary take the next larger variant), without losing anything 
important.

As regards case (c), for enumerations we can and should create a menu of 
choices. Bit fields should have either a dedicated basic type (bitfield 
with a configurable number of elements) or else be just an array of 
booleans, that gets automatically optimized into a bitfield.

The bottom line is that unsigned types should be used only in the very 
few cases where they are essential to faithfully represent raw hardware 
values.

Ben

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System