Experimental Physics and
Industrial Control System

Mark Rivers <[email protected]> · Fri, 15 Aug 2014 15:34:28 +0000

But I think there is a limitation with EPICS 3.14 because there is no architecture-independent definition of 64-bit integer data types.  The 64-bit types epicsInt64 and epicsUIn64 are only defined if __STDC_VERSION__ >= 199901L.  There are a number of architectures that support 64-bit integers (e.g. Windows) but don't define the EPICS types because they fail the STDC_VERSION test.

Mark

________________________________________
From: [email protected] [[email protected]] on behalf of Andrew Johnson [[email protected]]
Sent: Friday, August 15, 2014 10:20 AM
To: [email protected]
Subject: Re: Problem with creating an array of Long with aSub record

Lets give a definitive and cross-platform answer to the original
question: A LONG field-type is a DBF_LONG which gets instantiated as an
epicsInt32 value. The epicsIntNn typedefs are found in epicsTypes.h and
map to the appropriately sized integer on all architectures. We even
have tests that check the type sizes nowadays!

Please use the EPICS types in all your published EPICS code rather than
the equivalent C99 sized types (e.g. int32_t) because some of our
architectures do not support C99.

- Andrew

On 08/15/2014 08:09 AM, Mark Rivers wrote:
> Just to add to the confusion:
>
>> In EPICS LONG means 32-bits, but in 64-bit C it means 64 bits.  You need an array of int not long!
>
> A "long" on 64-bit Linux is 64 bits.  But a "long" on 64-bit Windows is still only 32 bits.  Pointers are 64 bits, but not longs.  The "long long" datatype is 64 bits on Windows (and most other platforms).
>
> Mark
>
>
> ________________________________________
> From: [email protected] [[email protected]] on behalf of [email protected] [[email protected]]
> Sent: Friday, August 15, 2014 7:32 AM
> To: [email protected]; [email protected]
> Subject: RE: Problem with creating an array of Long with aSub record
>
> Your problem is a confusing difference in the meaning of "long".
>
> In EPICS LONG means 32-bits, but in 64-bit C it means 64 bits.  You need an array of int not long!
> ________________________________________
> From: David Michel [[email protected]]
> Sent: 15 August 2014 12:41
> To: EPICS mailing list
> Subject: Fwd: Problem with creating an array of Long with aSub record
>
> Oops... please ignore my previous post... somehow pressed the send button by mistake.
>
> ===========
>
> Hi All,
>
> I was toying around with an aSub Record to get it to generate an array...
>
> So I've got this code:
>
> static long gen_array(aSubRecord *precord)
> {
>     long lx=1292;
>
>     long arr[lx];
>     long i=0;
>     for (i=0;i<lx;i++)
>     {
>          arr[i] = i;
>     }
>     memcpy(precord->vala,arr,precord->nova*sizeof(long));
>
>     return 0;
> }
>
> and this record:
>
> record(aSub, "MyASubRecord") {
>     field(SNAM, "gen_array")
>     field(FTVA, "LONG")
>     field(NOVA, "1292")
> }
>
>
> Given the value of lx, I would expect to see VALA with 0,1,2,3,4...1291
>
> But I do a caget MyASubRecord.VALA, I get this:
>
> MyASubRecord.VALA 1292 0 0 1 0 2 0 3 0 4... 644 0 645 0
>
> The number of elements is correct, i.e. 1292, but there are 0s interlaced with the correct data ??? I'm sure it's something silly, but I cannot figure it out.
>
>
> Thanks
> David
>
>
>
>
> --
> This e-mail and any attachments may contain confidential, copyright and or privileged material, and are for the use of the intended addressee only. If you are not the intended addressee or an authorised recipient of the addressee please notify us of receipt by returning the e-mail and do not use, copy, retain, distribute or disclose the information in or attached to the e-mail.
> Any opinions expressed within this e-mail are those of the individual and not necessarily of Diamond Light Source Ltd.
> Diamond Light Source Ltd. cannot guarantee that this e-mail or any attachments are free from viruses and we cannot accept liability for any damage which you may sustain as a result of software viruses which may be transmitted in or with the message.
> Diamond Light Source Limited (company no. 4375679). Registered in England and Wales with its registered office at Diamond House, Harwell Science and Innovation Campus, Didcot, Oxfordshire, OX11 0DE, United Kingdom
>
>
>
>
>
>

--
Advertising may be described as the science of arresting the human
intelligence long enough to get money from it. -- Stephen Leacock

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System