Experimental Physics and Industrial Control System
>> The crux here is that a "dbr_long_t" is an "epicsInt32",
>> and an epicsInt32 is currently an "int".
>
> I'm not quite sure what Jeff's point is,
My point is that in the CA API DBR_LONG selects a dbr_long_t which is an
"epicsInt32" which is an "int" which is a 32 bit signed integer on all
platforms that we support today. For the CA client library that includes
alphas which implement type "int" as a 32 bit integer. I have not heard
of a 64 bit C compiler or a 32 bit C compiler that chose otherwise.
> but if you ignore what
> I wrote (which was worded before I had completely understood
> Paul's message) the important issue here is that in the two
> definitions of dbr_time_double, one of them effectively
> uses int RISC_pad and the other long RISC_pad.
The correct architecture independent definition in db_access.h uses
architecture independent types such as dbr_long_t. Type "long" is
different between 32 bit hosts and 64 bit hosts, and is therefore
particularly problematic.
> Paul suggests using int, and has confirmed that this
> works. Does it need any more discussion?
You should not use type "int" because, in the future, we might come
across an architecture where type "int" is not 32 bits. I would
recommend an architecture independent type such as dbr_long_t since this
is in a DBR_XXX interface, but epicsInt32_t would be ok also.
> One of them needs changing for CA to work properly on any
> architecture where
> sizeof int != sizeof long
I would recommend maintaining only one definition in db_accces.h! This
will prevent things from getting out of sync.
If there is something in db_access.h that db_access.c must not see then
we should probably selectively ifndef them out. Of course db_access.c
would need to #define some macro that enables this as follows.
In db_access.h:
#ifndef DB_ACCESS_C
#define DBR_XXX
..
..
..
#endif
in db_access.c
#define DB_ACCESS_C
#include "db_access.h"
Jeff
> -----Original Message-----
> From: Andrew Johnson [mailto:[email protected]]
> Sent: Wednesday, December 04, 2002 10:23 AM
> To: Jeff Hill
> Cc: 'Marty Kraimer'; 'Janet Anderson'; [email protected];
> 'TYLER, Paul'
> Subject: Re: RISC_pad in dbr_time_double
>
> I'm not quite sure what Jeff's point is, but if you ignore what
> I wrote
> (which was worded before I had completely understood Paul's
> message) the
> important issue here is that in the two definitions of
> dbr_time_double,
> one of them effectively uses int RISC_pad and the other long
> RISC_pad.
> One of them needs changing for CA to work properly on any
> architecture where
> sizeof int != sizeof long
>
> Paul suggests using int, and has confirmed that this works.
> Does it need
> any more discussion? Granted someone should probably check the
> other dbr_
> types too, now we know there is a potential problem. I doubt
> if there is
> anywhere else that is likely to have two definitions of the
> same structure
> as this only comes about because of the dbAccess.h/db_access.h
> mismatch.
>
> - Andrew
> --
> "Life is what happens while you're busy making other plans." -
> John Lennon
- References:
- Re: RISC_pad in dbr_time_double Andrew Johnson
- Navigate by Date:
- Prev:
RE: RISC_pad in dbr_time_double Jeff Hill
- Next:
Re: RISC_pad in dbr_time_double Marty Kraimer
- Index:
<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: RISC_pad in dbr_time_double Andrew Johnson
- Next:
Re: RISC_pad in dbr_time_double Marty Kraimer
- Index:
<2002>
2003
2004
2005
2006
2007
2008
2009
2010
2011
2012
2013
2014
2015
2016
2017
2018
2019
2020
2021
2022
2023
2024