Experimental Physics and
Industrial Control System

Andrew Johnson <[email protected]> · Thu, 29 May 2008 11:48:01 -0500

Eric Norum wrote:
> Andrew Johnson wrote:

../../asyn/devEpics/devAsynInt32.c: In function 'processMbbo':

../../asyn/devEpics/devAsynInt32.c:717: warning: assignment from

incompatible pointer type

../../asyn/devEpics/devAsynUInt32Digital.c: In function 'processMbbo':

../../asyn/devEpics/devAsynUInt32Digital.c:578: warning: assignment

from incompatible pointer type

../../asyn/devGpib/devCommonGpib.c: In function 'devGpib_initMbbi':

../../asyn/devGpib/devCommonGpib.c:657: warning: assignment from

incompatible pointer type

../../asyn/devGpib/devCommonGpib.c: In function 'devGpib_initMbbo':

../../asyn/devGpib/devCommonGpib.c:839: warning: assignment from

incompatible pointer type

On what compiler? I get no warnings for those -- the LHS and RHS of the

assignments are both 'unsigned long *'.

I didn't look at them closely before, sorry; this is GCC on a 64-bit

machine with some uncommitted changes I have in in my tree for 64-bit

systems that change the expansion of DBF_ULONG fields from 'unsigned

long' to 'epicsUInt32', etc.

This all relates to differences between db_access.h and dbAccess.h. For

code using db_access.h as provided by CA, DBF_LONG maps to an epicsInt32

(which is actually an int), whereas for code using dbAccess.h from the

database a DBF_LONG used to map directly to a regular long. On 64-bit

CPUs though these two are not synonymous.

Despite this in most cases the existing database code is self-consistent

and works Ok on 64-bit systems, but there are a few obscure spots where

bugs show up, such as when requesting a DBR_GRAPHIC_DOUBLE through CA

from a 64-bit IOC (IIRC the precision value is wrong). I think it's

important that R3.14.10 properly supports 64-bit systems, so something

has to be done.

I recently worked on fixing the database and dbAccess to change code

that uses 'long' to make it use epicsInt32 instead. My changes only

affect the field types generated when expanding the record.dbd files,

not the recGbl APIs or RSET routine arguments, so the modifications

needed in the record supports as a result of this are mostly minor and

in many cases zero.

Unfortunately if I commit these changes (which provide a comprehensive

solution) this will probably require *some* out-of-tree device and

record support changes to match, as in the above warnings from asyn

which are from pointers to the DBF_LONG state value fields (ZRVL etc) of

the MBB* record types.

It might be possible to reduce the impact of the fix while still getting

the IOC to work properly on 64-bit CPUs by not making DBF_LONG fields

become an epicsInt32 type. In this case, my current changes would move

to the main trunk for the R3.15 release.

My question for general developer discussion is therefore which solution

should we adopt? Do it properly in R3.14.10, so on all architectures a

DBF_LONG is 32 bits wide but some external device and record support

code needs changing, or just fix up the code in R3.14.10 so it works on

64-bit IOCs but a DBF_LONG field is architecture-specific?

I am inclined to do it properly in R3.14.10.  Comments?

- Andrew
--
Talk is cheap. Show me the code. -- Linus Torvalds

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System