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;
 + --
 +  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>