Argonne National Laboratory

Experimental Physics and
Industrial Control System

2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  <2017 Index 2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  <2017
<== Date ==> <== Thread ==>

Subject: RE: const-constraints on struct rset method arguments
From: "Mooney, Tim M." <mooney@aps.anl.gov>
To: Ben Franksen <benjamin.franksen@helmholtz-berlin.de>, "core-talk@aps.anl.gov" <core-talk@aps.anl.gov>
Date: 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 (mooney@aps.anl.gov) (630)252-5417
Beamline Controls Group (www.aps.anl.gov)
Advanced Photon Source, Argonne National Lab


________________________________________
From: core-talk-bounces@aps.anl.gov [core-talk-bounces@aps.anl.gov] on behalf of Ben Franksen [benjamin.franksen@helmholtz-berlin.de]
Sent: Monday, February 27, 2017 5:48 PM
To: core-talk@aps.anl.gov
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



Replies:
Re: const-constraints on struct rset method arguments Benjamin Franksen
References:
const-constraints on struct rset method arguments Ben Franksen

Navigate by Date:
Prev: const-constraints on struct rset method arguments Ben Franksen
Next: Re: const-constraints on struct rset method arguments Benjamin Franksen
Index: 2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  <2017
Navigate by Thread:
Prev: const-constraints on struct rset method arguments Ben Franksen
Next: Re: const-constraints on struct rset method arguments Benjamin Franksen
Index: 2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  <2017
ANJ, 03 Mar 2017 Valid HTML 4.01! · Home · News · About · Base · Modules · Extensions · Distributions · Download ·
· EPICS V4 · IRMIS · Talk · Bugs · Documents · Links · Licensing ·