Hi Joseph, On 11/15/21 21:18, Joseph Myers wrote:
lvalue-to-rvalue conversion loses qualifiers, which makes any rules based on whether the RHS of an assignment was nonnull-qualified very problematic. (The specification of restrict is exceedingly tricky and very unlikely to be a good basis for specifying any other feature.)
Hmm. restrict was the closest thing to a const-like level of safety that I could think of. It would allow a compiler to keep track of nullness of every pointer, and issue appropriate diagnostics probably better than what -fanalyzer already does. How is restrict handling that problem of lvalue-to-rvalue already? Can you think of any other way nonnull-ness could be passed to nested function calls with language enforcement? The other option would be to propose plain [[gnu::nonnull]], which couldn't be enforced across nested function calls (or I could't think of how yet). Well, the simplest cases (i.e., not pointer-to-pointer) could be detected by the compiler, but other than that, it's impossible. But if that's the only way, it's better than nothing.
I don't think a manpage is a good form for proposing a language feature. Actual proposed normative wording for the C standard, showing all relevant changes to all relevant subclauses, is better.
My intention is that the final PDF to be sent to the committee will have those diffs. But I have no clue of how to do that kind of things, so for an initial draft to discuss on, before even presenting it to the committee, I think my "native" language for writing technical documents will be easier. Also, I'm curious, do you do those diffs usually by hand? I mean, you can't diff(1) a PDF, can you? :) Considering that C moves at a 10-years pace, and we're late for C2X, I have until around 2030 to learn how to do that :-) Thanks! and kind regards, Alex -- Alejandro Colomar Linux man-pages comaintainer; http://www.kernel.org/doc/man-pages/ http://www.alejandro-colomar.es/
