EPICS Controls Argonne National Laboratory

Experimental Physics and
Industrial Control System

1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  <20142015  2016  2017  2018  2019  2020  2021  2022  2023  2024  Index 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  <20142015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
<== Date ==> <== Thread ==>

Subject: Re: Small bug in caget
From: Andrew Johnson <[email protected]>
To: <[email protected]>, <[email protected]>
Date: Fri, 21 Nov 2014 12:23:16 -0600
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. 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.

Further discussion welcome…

- Andrew
-- 
People everywhere confuse what they read in newspapers with news.
-- A. J. Liebling

Replies:
Re: Small bug in caget Benjamin Franksen
RE: Small bug in caget michael.abbott
References:
Small bug in caget michael.abbott

Navigate by Date:
Prev: RE: epicsqt QETable or QElabel for waveforms readout Emmanuel Mayssat
Next: RE: epicsqt QETable or QElabel for waveforms readout Emmanuel Mayssat
Index: 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  <20142015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
Navigate by Thread:
Prev: Small bug in caget michael.abbott
Next: Re: Small bug in caget Benjamin Franksen
Index: 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  <20142015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
ANJ, 17 Dec 2015 Valid HTML 4.01! · Home · News · About · Base · Modules · Extensions · Distributions · Download ·
· Search · EPICS V4 · IRMIS · Talk · Bugs · Documents · Links · Licensing ·