Hi, I see that gnulib uses const/pure/reproducible/unsequenced function attributes, so I think it would be interesting to float here this draft of a C2y proposal that I'm working on at the moment.
Please let me know any feedback.
Have a lovely day!
Alex
---
Name
alx-0087r4 - 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 <[email protected]>
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).
r4 (2026-02-14):
- Disallow defining non-const static objects within such
functions.
- tfix
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 clearly 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;
+ --
+ a definition of
+ an object of static storage duration
+ with non-const-qualified type.
@@ 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>
signature.asc
Description: PGP signature
