Experimental Physics and
Industrial Control System

"Mooney, Tim M." <[email protected]> · Tue, 22 Jul 2014 21:01:32 +0000

Thanks for reporting this.  I've changed "unsigned long" to "epicsUInt32" in references to the Sn and PRn fields
in the scaler record, and committed to subversion.  ("unsigned long" also occurs in casts of arguments in calls to device support; those, of course, should not be changed.)
Tim
________________________________________
From: Henrique Dante de Almeida [[email protected]]
Sent: Tuesday, July 22, 2014 12:07 PM
To: [email protected]
Cc: Mooney, Tim M.
Subject: synApps usage on 64 bit systems

Hello, while using synApps with a test scaler IOC in a 64 bit linux machine I noticed some problems while reading and writing PV values. The problem was tracked down by another developer, some time ago, to be in synApps/support/std-*/src/scalerRecord.c, where the scalerRecord elements pr1, pr2, etc. are accessed using an unsigned long pointer (a type coercion to handle them as if they were a simple array). For example, in process():

static long process(pscal)
scalerRecord *pscal;
{
(...)
        unsigned long *ppreset = (unsigned long *)&(pscal->pr1);
(...)

Since pr1 and all other pr* are type epicsUInt32, using ppreset to access
the preset values is not supposed to work. Can anyone confirm this ?

The proposed patch was to replace the cast to unsigned long * to epicsUInt32 *,
or similar. Changing only process() and updateCounts() to use a 32 bit type was
enough to make the test scaler to work. I noticed that there are other variables
of type unsigned long, though. Would it make sense to write a patch to change all
the relevant variables to a fixed 32 bit type ?

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System