RE: Fundamental Types document

["Jeff Hill" <johill@lanl.gov>]

> -----Original Message-----
> From: Marty Kraimer [mailto:mrk@aps.anl.gov]
> > Jeff Hill wrote:
> 
> >>The current definition of epicsTypes does NOT include unsigned
> >>types. The reason is Java. If we allow unsigned types it makes
> >>it very difficult to complely support Java.
> >>
> >>
> >
> >There is possibly another way of looking at this. With Java we must use
> an
> >integer type that has sufficient range to hold the magnitude of the
> integer
> >number used in C. This statement is true irregardless of whether the C
> type
> >is a signed or unsigned integer. Data Access will of course detect
> problems
> >where the integer magnitude in the server does not map to the range of
> the
> >data type of the client, and report them as exception call backs.
> >
> Two comments.
> 
> 1) If native type is an unsigned 64 bit, then there is no wider java type

My point was that even if an unsigned 64 bit integer is used in the server
it's very rare that we will have a need for the magnitude of the number
stored therein to use the portion of the range that can't be expressed in a
64 built signed integer. We should use unsigned numbers because of their non
negative domain, and not because of their increased range. Since we have
good detection at runtime for rare situations where there is an out of range
violation, and this detection is based on the numbers magnitude, and not
just the source and destination data types, then I think that this is a
reasonable compromise.

> 2) If each end is just using the unsigned as a bit mask (Note that Java
> provides for this) then throwing exceptions in the intermediate layers
> is no good.

My point was that if the bit fields are addressable by starting bit and bit
width it will be very rare that we need a full 64 bit width bit field.

Note that in robust programs exceptions are caught. If an exception occurs
in the server it is always caught and an exception message is sent to the
client. That results in a IO completion failure callback to the user.

Jeff