>
> So, I would like to propose changing the ULONG mapping to LONG, so that it
> can be fetched in native type and correctly recognized as being an integer.
>
> Comments?
>
My position is that mapping ULONG to LONG results in a sloppy API which
could influence existing general purpose clients to break in unexpected
ways. How can we predict what range of numbers will be used by the
EPICS community. This could result in bugs that would not easily be
detected during operation. This is also not a backwards compatible change.
I propose that we add dbr_ulong_t and dbr_ushort_t to the CA client API.
Requests for these types would of course be refused when they are
issued to old servers.
It is also possible that we should add new DBR_XXX types that would allow the
client to determine if the PV it is attached to is analog/binary and in/out.
This would perhaps directly address the underlying cause of Chip's troubles
(he is using the native type of the PV to guess that the PV is one of
analog/binary). Matthias has requested a new DBR_XXX type that would
return the record type as a string.
Jeff
- Replies:
- Re: change in promotion of types from database to channel access Chip Watson
- Navigate by Date:
- Prev:
database check in R3.13.0 (fwd) Johnny Tang
- Next:
RE: change in promotion of types from database to channel access Jeff Hill
- 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:
change in promotion of types from database to channel access Chip Watson
- Next:
Re: change in promotion of types from database to channel access Chip Watson
- 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
|