Brian McAllister wrote:
>
> >>> On 8/15/2001 at 8:49:13 CDT, Marty Kraimer wrote:
>
> > I am not aware of any plans to change the current mappings which are:
>
> > epicsShareDef unsigned short dbDBRnewToDBRold[newDBR_ENUM+1] = {
> > 0, /*DBR_STRING to DBR_STRING*/
> > 4, /*DBR_CHAR to DBR_CHAR*/
> > 4, /*DBR_UCHAR to DBR_CHAR*/
> > 1, /*DBR_SHORT to DBR_SHORT*/
> > 5, /*DBR_USHORT to DBR_LONG*/
> > 5, /*DBR_LONG to DBR_LONG*/
> > 6, /*DBR_ULONG to DBR_DOUBLE*/
> > 2, /*DBR_FLOAT to DBR_FLOAT*/
> > 6, /*DBR_DOUBLE to DBR_DOUBLE*/
> > 3, /*DBR_ENUM to DBR_ENUM*/
> > };
>
> Why is USHORT promoted to LONG, but UCHAR mapped to CHAR (rather than
> SHORT) ?
These decisions were made many years ago so the following is a best guess at the
thinking.
Except for UCHAR => CHAR the other mappings preserve precision, i.e. all values
from the source can be represented in the destination. As I recall the exception
was made because it was thought that 8 bit waveform digitizers would be widely
used. Thus it was not a good idea to map UCHAR to SHORT because of the increased
memory required.
Again in hindsight it would have been better to use uniform semantics but I
think it is too late to change.
Marty Kraimer
- References:
- Re: CA and unsigned types Brian McAllister
- Navigate by Date:
- Prev:
Re: CA and unsigned types Brian McAllister
- Next:
How to monitor 700 thermocouples? Rarback, Harvey
- Index:
1994
1995
1996
1997
1998
1999
2000
<2001>
2002
2003
2004
2005
2006
2007
2008
2009
2010
2011
2012
2013
2014
2015
2016
2017
2018
2019
2020
2021
2022
2023
2024
- Navigate by Thread:
- Prev:
Re: CA and unsigned types Brian McAllister
- Next:
Re: CA and unsigned types Brian McAllister
- Index:
1994
1995
1996
1997
1998
1999
2000
<2001>
2002
2003
2004
2005
2006
2007
2008
2009
2010
2011
2012
2013
2014
2015
2016
2017
2018
2019
2020
2021
2022
2023
2024
|