Experimental Physics and
Industrial Control System

Benjamin Franksen <[email protected]> · Tue, 5 Apr 2011 00:35:28 +0200

Am Montag, 4. April 2011, um 17:24:14 schrieben Sie:
> On Sunday 03 April 2011 11:34:39 Benjamin Franksen wrote:
> > since CA does not support 64bit integer types, I wonder what to do about
> > SNL programs with declarations like
> >
> > long x;
> > assign x to "whatever";
> >
> > on a system where sizeof(long)==8 (like linux-x86_64). Note that in SNL
> > code, the type of a variable determines the request type for CA requests.
> > In this case DBR_LONG is certainly wrong, as it is defined to be 32bit.
>
> Here's a naive question for FAQ purposes: Why can't you do what the
> database does and make the SNL 'long' type map to an epicsInt32 on all
> architectures? I personally understand the major disadvantage to doing
> that when interfacing to external APIs, but I think it's worth explaining
> exactly why you can't do that as part of this discussion.

Very good idea.

So, why not map an SNL 'long' to a C 'epicsInt32'? Well, as you already hinted
at, the main problem is that in SNL code you want to smoothly interoperate not
only with EPICS records via CA but also with C library functions. For
instance, many functions from the standard C library return long, e.g.
strtol(). I think it would be quite surprising to have SNL code like

unsigned long n = strtol(str,0,0);

result in a "warning: conversion from unsigned long to unsigned int may change
its value" or something similar. Or, even worse, to get *no* such warning and
instead get a completely wrong result due to overflow (i.e. the real result
modulo 2^32). This is an invitation for subtle, very hard to find bugs.

> I think making this an error is probably the right solution; the message
> should explain that the variable needs to be an int to assign it on any
> 64-bit systems, and the documentation should explain that the SNL code
> will need to marshal data values between two variables if the program
> really does need to use a 64-bit long variable.

Ok, I will try to give a nice error message in this case (currently it just
outputs the generic "a variable of this type cannot be assigned to a PV").

> > BTW, I doubt that the current stable version 2.0.12 works properly on
> > such systems but I haven't tried it yet.
>
> On little-endian (e.g. Intel/AMD) architecture systems the LSB is always at
> the pointed-to byte, thus long variables appear to work fine on most
> current 64-bit systems as long as the values are all within the positive
> 32-bit range. This will fail as soon as either side tries to use a
> negative value, but many sites may already be using this version without
> realizing the problem because of that.  It would be good to see a 2.0.13
> release with this fixed though, and the issue documented.

I think I can do that.

The problem I see is that 2.0.12 says

typedef long pvLong;

and then happily assigns pvLong from and to dbr_long_t. As you say, this is
not catastrophic in most cases, but I need to check if there are things like
sizeof(pvLong) used in places where in fact sizeof(dbr_long_t) would be
correct.

Cheers
Ben

________________________________

Helmholtz-Zentrum Berlin für Materialien und Energie GmbH

Mitglied der Hermann von Helmholtz-Gemeinschaft Deutscher Forschungszentren e.V

Aufsichtsrat: Vorsitzender Prof. Dr. Dr. h.c. mult. Joachim Treusch, stv. Vorsitzende Dr. Beatrix Vierkorn- Rudolph
Geschäftsführer: Prof. Dr. Anke Rita Kaysser-Pyzalla, Prof. Dr. Dr. h.c. Wolfgang Eberhardt, Dr. Ulrich Breuer

Sitz Berlin, AG Charlottenburg, 89 HRB 5583

Postadresse:
Hahn-Meitner-Platz 1
D-14109 Berlin

http://www.helmholtz-berlin.de

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System