Experimental Physics and Industrial Control System

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 Mooney, Tim M.

Navigate by Date:

Prev: RE: Why we want Lua on the IOC Hill, Jeff

Next: RE: const-constraints on struct rset method arguments Mooney, Tim M.

Index: 2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  <2017>  2018  2019  2020  2021  2022  2023  2024 

Navigate by Thread:

Prev: RE: Why we want Lua on the IOC Hill, Jeff

Next: RE: const-constraints on struct rset method arguments Mooney, Tim M.

Index: 2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  <2017>  2018  2019  2020  2021  2022  2023  2024