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
|