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>