Re: WG14 paper for removing restrict from nptr in strtol(3)

[Paul Eggert <eggert@cs.ucla.edu>]

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.