EPICS Controls Argonne National Laboratory

Experimental Physics and
Industrial Control System

<20022003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  Index <20022003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022 
<== Date ==> <== Thread ==>

Subject: RE: RISC_pad in dbr_time_double
From: "Jeff Hill" <[email protected]>
To: "'Andrew Johnson'" <[email protected]>
Cc: "'Marty Kraimer'" <[email protected]>, "'Janet Anderson'" <[email protected]>, <[email protected]>, "'TYLER, Paul'" <[email protected]>
Date: Wed, 4 Dec 2002 10:58:17 -0700
>> 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: <20022003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022 
Navigate by Thread:
Prev: Re: RISC_pad in dbr_time_double Andrew Johnson
Next: Re: RISC_pad in dbr_time_double Marty Kraimer
Index: <20022003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022 
ANJ, 02 Feb 2012 Valid HTML 4.01! · Home · News · About · Base · Modules · Extensions · Distributions · Download ·
· Search · EPICS V4 · IRMIS · Talk · Bugs · Documents · Links · Licensing ·