Experimental Physics and
Industrial Control System

Benjamin Franksen <[email protected]> · Tue, 5 Apr 2011 11:06:56 +0200

[Andrew, I meant to send my reply to the list, sorry. This is an edited and
extended version, BTW.]

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.

Why not map an SNL 'long' to a C 'epicsInt32'?

Well, I *could* of course do it like that, but I think it's not a good idea.

As Andrew 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

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

result in a "warning: conversion from long to int may change its value" or
something similar. Or, even worse, to get no such warning and instead,
depending on the input string, get a completely wrong result due to
overflow. I fear that this is an invitation for subtle, very hard to find
bugs.

BTW, Ralph Lange suggested that to make it easier to write portable SNL
code, I should allow use of the standard C fixed-size integer types in SNL.
This would mean you can say

uint32_t x;
assign x to "...";

and be sure that this is an unsigned 32 bit integer, regardless of
architecture and OS. I think this is a good idea and I plan to add this to
my development version, so it will be in 2.1, but not in 2.0.13.

> 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 main 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