Hi Paul, On 2026-02-14T09:43:47-0800, Paul Eggert wrote: > On 2026-02-14 08:30, Alejandro Colomar wrote: > > 6.7.12.1 Attributes :: Introduction > > @@ p0+1 > > Attributes are extremely dangerous, > > and will likely result in > > all kinds of vulnerabilities in code that uses them. > > Do not use them in any code that cares about safety. > > They're only useful to optimize code > > that cares nothing about safety.XXX) > > > > @@ New footnote > > XXX) > > The standard got rid of gets, > > so we felt something similar should replace it, > > to keep the balance of the universe. > > I assume that this is some sort of pointed remark about something else,
This is a pun at a large part of the committee, which defends that
attributes shall remain unsafe because that's their purpose.
Here's the first feedback I got from a member of the committee about
an early draft of this proposal:
I appreciate that there's a certain Barthesian tendency to disregard
authorial intent here, but intent is tightly coupled to the concept of
"purpose", and the constraints introduced by this proposal directly
contradict the stated purpose of the attributes, which is to override
analysis with local information, somehow known at the design level and
not
at the flow-analysis level.
I agree that _actually doing this_ is almost never a good idea*, it's
the
`restrict` issue again, but I don't think you can call this
"low-hanging"
while disregarding what the feature is designed to achieve.
It is designed to achieve a form of unsafety; that's not a mistake in
the
design, though.
That led me to add the pun above, to make it obvious that it's
ridiculous to keep it unsafe for no good reasons.
The wording of the footnote tries to be evident enough about it being
sarcastic.
> and
> is not seriously intended to go into the standard.
Nope; I don't intend to add that into the standard. :)
> As such, it detracts from
> the other, more important, proposal.
While I wouldn't have that in a proposal for a reasonable public,
I think it achieves its mission considering the intended audience:
the C Committee.
> > + A definition of
> > + a function declared with the <b>reproducible</b> attribute
> > + shall not contain,
> > + anywhere in the tokens making up the function definition:
> > + --
> > + a function call operator
> > + whose operand is
> > + a pointer to a function declared
> > + without the <b>reproducible</b> attribute;
>
> This is too strong. It's OK for a reproducible function's body to contain a
> call to a function not marked reproducible, so long as the call is never
> executed.
Yup; I intend to add exceptions for sizeof() and other operators that
don't evaluate their operands.
> This can happen when, for example, there's a debugging flag set at
> compile-time, and the flag is off so the compiler can easily determine the
> call cannot happen.
If you mean code that is stripped out by the preprocessor, it wouldn't
be a problem. This constraint applies after the preprocessor has done
its job.
>
> Similarly for the other parts of the proposed change.
Agree.
>
> PS. You *do* know that nobody really knows what [[reproducible]] means?
Yes, I'm aware. I'm starting to have an idea, though. I think by
having constraints, we'd eventually have a clear definition of what it
means: it would mean whatever is not disallowed.
> In
> Gnulib we mention it mostly as a thing to be avoided.
FWIW, the current guideline should be:
Do not ever use any standard attribute
(if you care about safety);
they are more dangerous than casts.
Have a lovely night!
Alex
--
<https://www.alejandro-colomar.es>
signature.asc
Description: PGP signature
