On 7/7/24 03:58, Alejandro Colomar wrote:
I've incorporated feedback, and here's a new revision, let's call it
v0.2, of the draft for a WG14 paper.
Although I have not followed the email discussion closely, I read v0.2
and think that as stated there is little chance that its proposal will
be accepted.
Fundamentally the proposal is trying to say that there are two styles X
and Y for declaring strtol and similar functions, and that although both
styles are correct in some sense, style Y is better than style X.
However, the advantages of Y are not clearly stated and the advantages
of style X over Y are not admitted, so the proposal is not making the
case clearly and fairly.
One other thing: to maximize the chance of a proposal being accepted,
please tailor it for its expected readership. The C committee is expert
on ‘restrict’, so don’t try to define ‘restrict’ in your own way. Unless
merely repeating the language of the standard, any definition given for
‘restrict’ is likely to cause the committee to quibble with the
restatement of the standard wording. (It is OK to mention some
corollaries of the standard definition, so long as the corollaries are
not immediately obvious.)
Here are some comments about the proposal. At the start these comments
are detailed; towards the end, as I could see the direction the proposal
was headed and was convinced it wouldn’t be accepted as stated, the
comments are less detailed.
"The API may copy"
One normally doesn’t think of the application programming interface as
copying. Please replace the phrase “the API” with “the caller” or “the
callee” as appropriate. (Although ‘restrict’ can be used in places other
than function parameters, I don’t think the proposal is concerned about
those cases and so it doesn’t need to go into that.)
"To avoid violations of for example C11::6.5.16.1p3,"
Code that violates C11::6.5.16.1p3 will do so regardless of whether
‘restrict’ is present. I would not mention C11::6.5.16.1p3 as it’s a red
herring. Fundamentally, ‘restrict’ is not about the consequences of
caching when one does overlapping moves; it’s about caching in a more
general sense.
“As long as an object is only accessed via one restricted pointer, other
restricted pointers are allowed to point to the same object.”
“only accessed” → “accessed only”
“This is less strict than I think it should be, but this proposal
doesn’t attempt to change that definition.”
I would omit this sentence and all similar sentences. Don’t distract the
reader with other potential proposals. The proposal as it stands is
complicated enough.
“return ca > a;”
“return ca > *ap;”
I fail to understand why these examples are present. It’s not simply
that nobody writes code like that: the examples are not on point. I
would remove the entire programs containing them, along with the
sections that discuss them. When writing to the C committee one can
assume the reader is expert in ‘restrict’, there is no need for examples
such as these.
“strtol(3) accepts 4 objects via pointer parameters and global variables.”
Omit the “(3)”, here and elsewhere, as the audience is the C standard
committee.
“accepts” is a strange word to use here: normally one says “accepts” to
talk about parameters, not global variables. Also, “global variables” is
not right here. The C standard allows strtol, for example, to read and
write an internal static cache. (Yes, that would be weird, but it’s
allowed.) I suggest rephrasing this sentence to talk about accessing,
not accepting.
“endptr access(write_only) ... *endptr access(none)”
This is true for glibc, but it’s not necessarily true for all conforming
strtol implementations. If endptr is non-null, a conforming strtol
implementation can both read and write *endptr; it can also both read
and write **endptr. (Although it would need to write before reading,
reading is allowed.)
“This qualifier helps catch obvious bugs such as strtol(p, p, 0) and
strtol(&p, &p, 0) .”
No it doesn’t. Ordinary type checking catches those obvious bugs, and
‘restrict’ provides no additional help there. Please complicate the
examples to make the point more clearly.
“The caller knows that errno doesn’t alias any of the function arguments.”
Only because all args are declared with ‘restrict’. So if the proposal
is accepted, the caller doesn’t necessarily know that.
“The callee knows that *endptr is not accessed.”
This is true for glibc, but not necessarily true for every conforming
strtol implementation.
“It might seem that it’s a problem that the callee doesn’t know if nptr
can alias errno or not. However, the callee will not write to the latter
directly until it knows it has failed,”
Again this is true for glibc, but not necessarily true for every
conforming strtol implementation.
To my mind this is the most serious objection. The current standard
prohibits calls like strtol((char *) &errno, 0, 0). The proposal would
relax the standard to allow such calls. In other words, the proposal
would constrain implementations to support such calls. Why is this
change worth making? Real-world programs do not make calls like that.
“But nothing prohibits those internal helper functions to specify that
nptr is restrict and thus distinct from errno.”
Although true, it’s also the case that the C standard does not *require*
internal helper functions to use ‘restrict’. All that matters is the
accesses. So I’m not sure what the point of this statement is.
“m = strtol(p, &p, 0); An analyzer more powerful than the current ones
could extend the current -Wrestrict diagnostic to also diagnose this case.”
Why would an analyzer want to do that? This case is a perfectly normal
thing to do and it has well-defined behavior.
“To prevent triggering diagnostics in a powerful analyzer that would be
smart enough to diagnose the example function g(), the prototype of
strtol(3) should be changed to ‘long int strtol(const char *nptr, char
**restrict endptr, int base);’”
Sorry, but the case has not been made to make any such change to
strtol’s prototype. On the contrary, what I’m mostly gathering from the
discussion is that ‘restrict’ can be confusing, which is not news.
n3220 §6.7.4.2 examples 5 through 7 demonstrate that the C committee has
thought through the points you’re making. (These examples were not
present in C11.) This may help to explain why the standard specifies
strtol with ‘restrict’ on both arguments.
