Skip to content

Commit 76f2bde

Browse files
committed
New issue from Jonathan: User defined macros without standard headers (294 redux)
1 parent b48e7cc commit 76f2bde

File tree

1 file changed

+80
-0
lines changed

1 file changed

+80
-0
lines changed

xml/issue4149.xml

Lines changed: 80 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,80 @@
1+
<?xml version='1.0' encoding='utf-8' standalone='no'?>
2+
<!DOCTYPE issue SYSTEM "lwg-issue.dtd">
3+
4+
<issue num="4149" status="New">
5+
<title>User defined macros without standard headers (294 redux)</title>
6+
<section><sref ref="[macro.names]"/></section>
7+
<submitter>Jonathan Wakely</submitter>
8+
<date>05 Sep 2024</date>
9+
<priority>99</priority>
10+
11+
<discussion>
12+
<p>
13+
Issue <iref ref="294"/> changed <sref ref="[macro.names]"/> from:
14+
<blockquote>
15+
A translation unit that includes a header shall not contain any macros that
16+
define names declared or defined in that header. Nor shall such a translation
17+
unit define macros for names lexically identical to keywords.
18+
</blockquote>
19+
to:
20+
<blockquote>
21+
A translation unit that includes a standard library header shall not
22+
`#define` or `#undef` names declared in any standard library header.
23+
<p>
24+
A translation unit shall not `#define` or `#undef` names lexically identical
25+
to keywords.
26+
</p>
27+
</blockquote>
28+
</p>
29+
<p>
30+
Note that the second sentence of the original says "such a translation unit"
31+
when prohibiting things like `#define while`. This means the prohibition only
32+
applies to "a translation unit that includes a header".
33+
The replacement has the prohibition in a separate paragraph and does not
34+
clearly say that it only applies when a header is included.
35+
</p>
36+
<p>
37+
The issue discussion seems clear that the concern is about C++ headers
38+
including other unspecified headers, which is allowed in C++ (though not in C).
39+
There is no justification for broadening the second sentence to apply
40+
unconditionally. Such a rule would belong in <sref ref="[cpp]"/> anyway,
41+
not in library wording. That overreach doesn't appear to have been intended,
42+
and we should clarify what the library is prohibiting.
43+
</p>
44+
<p>
45+
It was pointed out on the reflector that it's not enough to only prohibit
46+
defining such macros <i>after</i> including headers, because in some cases
47+
that could still break the library header. For example, the library macro
48+
`assert` typically uses `void` and so `#define void ...` would break `assert`
49+
even if it happens after including <code>&lt;cassert&gt;</code>.
50+
</p>
51+
</discussion>
52+
53+
<resolution>
54+
<p>
55+
This wording is relative to <paper num="N4986"/>.
56+
</p>
57+
58+
<ol>
59+
<li><p>Modify <sref ref="[macro.names]"/> as indicated:</p>
60+
61+
<blockquote>
62+
<p>
63+
-1- A translation unit that includes a standard library header shall not
64+
`#define` or `#undef` names declared in any standard library header.
65+
</p>
66+
<p>
67+
-2- A translation unit
68+
<ins>that includes a standard library header</ins>
69+
shall not `#define` or `#undef` names lexically identical to keywords,
70+
to the identifiers listed in Table 4,
71+
or to the <i>attribute-tokens</i> described in <sref ref="[dcl.attr]"/>,
72+
except that the names `likely` and `unlikely` may be defined as
73+
function-like macros (<sref ref="[cpp.replace]"/>).
74+
</p>
75+
</blockquote>
76+
</li>
77+
</ol>
78+
</resolution>
79+
80+
</issue>

0 commit comments

Comments
 (0)