Experimental Physics and
Industrial Control System

"Mooney, Tim M." <[email protected]> · Thu, 2 Mar 2017 22:16:03 +0000

Dear folks,

Andrew invited us to weigh in on this thread.  I'm all in favor of type checking RSET function-pointer arguments.
I don't mind warnings if I specify arguments of type "DBADDR*" instead of "const DBADDR*", but I feel this const business is less beneficial than type checking.  (Also, I still have a bunch of arguments specified as "struct dbAddr *".)

I guess the bottom line for me is that I don't mind changes that require even a fair amount of editing if there is a syntax that at least works for several versions of base.

Tim Mooney ([email protected]) (630)252-5417
Beamline Controls Group (www.aps.anl.gov)
Advanced Photon Source, Argonne National Lab

________________________________________
From: [email protected] [[email protected]] on behalf of Ben Franksen [[email protected]]
Sent: Monday, February 27, 2017 5:48 PM
To: [email protected]
Subject: const-constraints on struct rset method arguments

Background: Since ancient times, support interfaces like 'struct rset'
declare the methods (function pointers) in tables as e.g. RECSUPFUN
which is a synonym for 'long (*) ()', which in C means 'any number and
type of arguments'. This is true of record, device, and driver support,
but for practical reasons I want to limit the discussion to record
support. A recently discovered bug in base would have been found years
ago if the interface would not disable type checking here.

I have been working on a way to get us typed record support methods, for
base 3.16, taking compatibility questions (forward and backward) into
account.

This brought up the question of how to handle the const-ness of the
DBADDR* argument that many record support methods take. The code in base
that calls record support does call some of the methods with a const
DBADDR*. This will result in warnings when the type of the method
doesn't have the const, when compiled with gcc. However, when the code
is compiled with g++, as is the case for the motorRecord, then this is
an error (and, AFAIK, this is how the standard defines things, a few
remarks on that below).

Michael, who reviews my changes, commented:

> Well, one non-const situation (I'm to thank/blame) is
> get_array_info() which in >=3.15 is allowed to replace pfield. The
> caller is expected to save and replace it (see dbGet()). This enables
> a driver to use multiple buffers to avoid copying data into the
> record.

So we have to make a decision: do we want to specify const-ness of the
DBADDR parameter or is this too restricting w.r.t. future extensions? If
yes, for which methods?

  * * *

Side remark re C++ type checking of const: I think what the C++ compiler
does here (whether by following the standard or for other reasons) is
logically wrong: if I have a function

   void f(const int *p)

it is allowed to pass a non-const 'int*' (no warning) and for a good
reason. But I get a type error when I assign the address of f to a
pointer pf of type

   void (*pf)(int *p)

That doesn't make sense. Code that calls *pf must assume that the
function /can/ modify the int behind the pointer; if the function
refrains form doing so and states that in its type, what's wrong about that?

In short: const-checking does not take variance into account, and thus
issues an error even if the conversion would be safe. This is one of the
problems of prescribing const arguments in function tables.

Cheers
Ben

________________________________

Helmholtz-Zentrum Berlin für Materialien und Energie GmbH

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

Aufsichtsrat: Vorsitzender Dr. Karl Eugen Huthmacher, stv. Vorsitzende Dr. Jutta Koch-Unterseher
Geschäftsführung: Prof. Dr. Anke Rita Kaysser-Pyzalla, Thomas Frederking

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