> #define reproducible

This violates:

If the program defines a reserved identifier or standard attribute token
described in 6.7.13.2 as a macro name, or removes (with #undef) any macro
definition of an identifier in the first group listed previously or standard
attribute token described in 6.7.13.2, the behavior is undefined.

Section 6.4.2.1 Paragraph 9 ISO/IEC 9899:2024

This does mean that being able to use __reproducible__ and other attribute names
that both begin and end with two underscores is useless. Also:

Conversely, if a definition that does not have the asserted property is accessed
by a function declaration or a function pointer with a type that has the
attribute, the behavior is undefined.

Section 6.7.13.8.1 Paragraph 3 ISO/IEC 9899:2024

So even ignoring the issue of defining reproducible being undefined, all users
must equivalently define reproducible themselves to avoid undefined behavior.

> + 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 reference to a function
> + declared without the <b>reproducible</b> attribute.

Does this mean the following would be invalid:

int foo();
int(*bar()[[reproducible]])(){
return foo;
}

Or even more innocuously:

void baz()[[reproducible]]{
int qux();
}

Additionally, how would this work when considering functions which are later
defined as reproducible:

int a();
int b()[[reproducible]]{
return a();//appears invalid here
}
int a()[[reproducible]];//but becomes valid later

int c();
int d(){
return c();//appears valid here
}
int d()[[reproducible]];//but becomes invalid later

Or even both together:

int e();
int f(){
return e();//appears valid here
}
int f()[[reproducible]];//but becomes invalid later
int e()[[reproducible]];//then becomes valid again

Function pointers also do not seem to be included here:

void g(void h())[[reproducible]]{
h();//OK?
}

A lot of the standard library does not use [[reproducible]] or [[unsequenced]]
even if it should, this would make a lot of code invalid even if it was probably
relying on the implementation to not be malicious. For example stdckdint.h,
stdarg.h, offsetof, etc. If this is going to be a constraint then the use of
these attributes should increase in the standard library to not break so much
code.

> [[reproducible]] is unnecessarily dangerous. The same or very
> similar optimization goals could be achieved without a complete
> and irresponsible disregard for safety.

By the way, noreturn can also cause undefined behavior. If this is about making
undefined behavior harder to get then I think it would be worth including that
too, for example requiring no return statements. Possibly also requiring that
control flow never reaches the end by requiring an infinite loop or another call
to a noreturn function, or unreachable() to add the undefined behavior back.

> The committee is somehow acknowledging that attributes should
> be as dreaded as casts?! Why would we standardize these
> features in the first place?

Similar attributes had already existed before in GCC and Clang at least. It was
standardizing attributes that had already existed before.

On Fri, Feb 13, 2026 at 11:26 AM Alejandro Colomar via Std-Proposals
<std-proposals_at_[hidden]> wrote:
>
> Hi,
>
> I've started a new thread, since this is not about NRVO.
>
> Here's a draft of a proposal I'm working on for ISO C, to start making
> attributes safer. It's only the start, so don't blame me for falling
> short. I just want to reach some consensus before we can continue
> further.
>
>
> Have a lovely day!
> Alex
>
> ---
> Name
> alx-0087r1 - 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.
>
> 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
> #define reproducible
> #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 reference to a function
> + declared without the <b>reproducible</b> attribute.
> +0+2
> + A function declared with the <b>reproducible</b> attribute
> + shall not write to any object
> + other than through the parameters of the function.
>
> @@ 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 reference to a function
> + declared without the <b>unsequenced</b> attribute.
> +0+2
> + A function declared with the <b>unsequenced</b> attribute
> + shall not read from any object
> + other than through the parameters of 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>
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals