On 2026-02-14T14:06:59+0100, Alejandro Colomar wrote:
> Hi!
>
> Here's a revision of the draft proposal for ISO C2y that I sent
> yesterday. It addresses some concerns reported.
>
> This still doesn't make these two attributes perfect, nor fixes
> attributes in general, but it's a less controversial start, I think.
> Once there's agreement on this, it would make sense to tackle other
> issues.
>
>
> Have a lovely day!
> Alex
>
> ---
> Name
> alx-0087r3 - reproducible constraints
>
> Principles
> - Codify existing practice to address evident deficiencies
> - Enable secure programming
>
> And from the old C23 charter:
>
> - Trust the programmer, as a goal, is outdated in respect to
> the security and safety programming communities.
>
> Category
> Earthly demon.
>
> Author
> Alejandro Colomar <alx_at_[hidden]>
>
> History
> <https://www.alejandro-colomar.es/src/alx/alx/std/wg14/alx-0087.git/>
>
> r0 (2026-02-11):
> - Initial draft.
>
> r1 (2026-02-13):
> - Document a better way to override compiler analysis.
>
> r2 (2026-02-13):
> - Concepts: Add pointer provenance clause.
> - Use 'derived from' to ensure that local variables are
> allowed.
> - Disallow accessing volatile objects.
> - We only need to disallow the function call operator, not
> every reference to a function.
>
> r3 (2026-02-14):
> - Don't use 'derived', as it's a run-time property. Instead,
> ban references to objects within operands to certain
> operators (or anywhere, in some cases).
>
> Description
> [[reproducible]] is unnecessarily dangerous. The same or very
> similar optimization goals could be achieved without a complete
> and irresponsible disregard for safety.
>
> Moreover, there are proposals like n3499 which somehow creep in
> this dangerous feature in core parts of the language, which is
> even more worrying.
>
> We can add obvious constraints, to at least make this less of
> a weapon of mass-invocation of Nasal Demons. This doesn't fully
> fix this attribute, and I plan to do more work, but this is the
> essential first step.
>
> As far as I can imagine, the one "benefit" of this lack of
> constraints is allowing programmers to override compiler
> analysis with functions that have debug code that violates the
> rules of the attribute. For example, one may ++ a counter each
> time strlen(3) is called. However, this is already possible in
> C by giving different information to different translation
> units.
>
> // f.h
> [[reproducible]] int f(void);
>
> // f.c
> // Do NOT include "f.h"
>
> int
> f(void)
> {
> static int i;
>
> return i++;
> }
>
> This is a more idiomatic C way of lying to the compiler. And it
> has the advantage that it's more explicit, so that the user has
> to opt in to the unsafety, instead of praying to $deity that it
> didn't accidentally write UB every time it uses an attribute.
>
> A member of the C Committee stated:
>
> > \* though personally I think QoI is satisfied by an
> > unconditional warning about use of these attributes;
> > safety-oriented users simply shouldn't be using this at all
>
> The committee is somehow acknowledging that attributes should
> be as dreaded as casts?! Why would we standardize these
> features in the first place? Our charter clarly talks against
> this. We might as well introduce a new paragraph at the
> beginning of 6.7.12.1:
>
> 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.
>
> See also
> <https://www.open-std.org/jtc1/sc22/wg14/www/docs/n3499.pdf>
> That proposal is very dangerous.
>
> Proposed wording
> Based on N3783.
>
> 6.7.12.8.2 The reproducible type attribute
> @@
> +Constraints
> +0+1
> + 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;
> + --
> + an lvalue with volatile-qualified type;
> + --
> + an increment or decrement operator
> + whose operand contains a reference to
> + an object not defined within the function;

Oops; I forgot to say

 ... or an object with static storage duration.

(everywhere)

> + --
> + an assignment operator
> + whose left operand contains a reference to
> + an object not defined within the function;
> + --
> + a unary <tt>&</tt> operator
> + whose operand contains a reference to
> + an object not defined within the function;
> + --
> + a reference to
> + an array object not defined within the function
> + that is not
> + the operand of an indirection operator;
>
> @@ Description, p1
> The reproducible type attribute
> -asserts that
> +marks
> a function or pointed-to function with that type
> -is
> +as being
> reproducible.
>
>
> 6.7.12.8.3 The unsequenced type attribute
> @@
> +Constraints
> +0+1
> + A definition of
> + a function declared with the <b>unsequenced</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>unsequenced</b> attribute,
> + --
> + a reference to
> + an object not defined within the function.
>
> @@ Description, p1
> The unsequenced type attribute
> -asserts that
> +marks
> a function or pointed-to function with that type
> -is
> +as being
> unsequenced.
>
> @@
> +Semantics
> +7+1
> + The <b>unsequenced</b> attribute
> + implies the <b>reproducible</b> attribute.
>
> --
> <https://www.alejandro-colomar.es>

-- 
<https://www.alejandro-colomar.es>