Experimental Physics and
Industrial Control System

"Jeff Hill" <[email protected]> · 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

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System