-
Notifications
You must be signed in to change notification settings - Fork 0
/
Copy pathEmptyLvalues.html
430 lines (423 loc) · 24.2 KB
/
EmptyLvalues.html
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<style type="text/css">
<style type="text/css">
body { color: #000000; background-color: #FFFFFF; }
ins, ins * { text-decoration:none; font-weight:bold; background-color:#A0FFA0 }
del, del * { text-decoration:line-through; background-color:#FFA0A0 }
#hidedel:checked ~ * del, #hidedel:checked ~ * del * { display:none; visibility:hidden }
p.example { margin-left: 2em; }
pre.example { margin-left: 2em; }
div.example { margin-left: 2em; }
code.extract { background-color: #F5F6A2; }
pre.extract { margin-left: 2em; background-color: #F5F6A2;
border: 1px solid #E1E28E; }
p.function { }
.attribute { margin-left: 2em; }
.attribute dt { float: left; font-style: italic;
padding-right: 1ex; }
.attribute dd { margin-left: 0em; }
blockquote.std { color: #000000; background-color: #F1F1F1;
border: 1px solid #D1D1D1;
padding-left: 0.5em; padding-right: 0.5em; }
blockquote.stddel { text-decoration: line-through;
color: #000000; background-color: #FFEBFF;
border: 1px solid #ECD7EC;
padding-left: 0.5empadding-right: 0.5em; ; }
blockquote.stdins {
color: #000000; background-color: #C8FFC8;
border: 1px solid #B3EBB3; padding: 0.5em; }
blockquote pre em { font-family: normal }
table { border: 1px solid black; border-spacing: 0px;
margin-left: auto; margin-right: auto; }
th { text-align: left; vertical-align: top;
padding-left: 0.8em; border: none; }
td { text-align: left; vertical-align: top;
padding-left: 0.8em; border: none; }
ul { list-style-type: none; }
a { text-decoration: none; }
ul > li:before {
content: "\2014";
position: absolute;
margin-left: -1.5em;
}
</style>
</head>
<body>
<div style="text-align: right; float: right;">
<p>ISO/IEC JTC1 SC22 WG21, Core Working Group<br>
DxxxxR0<br>
Robert Haberlach (rh633{at}cam{dot}ac.uk)<br>
2017-04-21
</p>
</div>
<h1>Assignment categories of glvalues</h1>
This paper proposes to introduce, amongst other things, the notion of an empty lvalue as discussed
in core issue 232.<sup><a href="#CWG232">CWG232</a></sup>
The wording is partly adapted from the proposed wording in that core issue
and core issue 453.<sup><a href="#CWG453">CWG453</a><br>
<br>
</sup> This proposal resolves both these core issues and core issue 504.<sup><a href="#CWG504">CWG504</a></sup>
<h2>Motivation and proposed resolutions</h2>
<p>The standard is unclear about its treatment of indirection through
null pointers and pointers past the end of an object; <tt>typeid</tt>
is specified to treat lvalues created by dereferencing a null pointer,
and the common idiom <tt>&arr[len]</tt> is currently undefined.
The standard is also unclear about its distinction of lvalues referring
to objects and merely storage. This proposal introduces rigorous classifications
of references and expressions and employs them to define these expressions flawlessly.
</p>
<p>As of the rework on value categories, non-<tt>void</tt> expressions are put into two classes: glvalues and prvalues. Prvalues are said to have a value;
and glvalues' “evaluation determines the identity of an object, bitfield or function”. However, while prvalues indeed always designate values,
glvalues do not necessarily evaluate to any member of that list. They can be invalid, or refer to memory locations that don't hold objects of the specified type. Some wording makes
silent assumptions about what glvalues refer to, which can make reasoning about the well-formedness difficult; then again,
other wording is straight out inconsistent. </p>
<h3>Assignment categories of expressions</h3>
…solve this issue by classifying the different states of a glvalue. More specifically, a glvalue can be
<ul>
<li>assigned to <ul>
<li>an object,</li>
<li>a function, or</li>
<li>allocated storage, or</li>
</ul></li>
<li>past the end of an object—i.e. refer to the hypothetical past-the-end object of an array —, or</li>
<li>null (this corresponds to what earlier papers called an “empty lvalue”), or</li>
<li>invalid.</li>
</ul>
<p>This covers all different possible states of a glvalue. Certain uses of unassigned lvalues are now defined, in particular
Lvalue Transformations and the unary <tt>&</tt> operator.</p>
<h3>References</h3>
<p>Finally, in conjunction with the rework on reference intialization and state, we propose that a reference shall not be
initialized with its own name. This makes code ill-formed with a
diagnostic required - note that all common implementations already
diagnose this as a warning. For further discussion on this topic, see
also SG12's mailing list.<sup><a href="#UB504">UB504</a></sup></p>
<h2>Proposed wording</h2>
This wording is relative to N4640.
<br>
<br>
<input id="hidedel" type="checkbox">Hide deleted wording
<p>3.7 [basic.stc] ¶4:</p>
<blockquote class="std"> When the end of the duration of a region of
storage is reached, the values of all pointers representing the address
of any part of the deallocated storage become invalid pointer values
([basic.compound])<ins>,
references designating any part of the deallocated storage become
invalid references (8.3.2 [dcl.ref]) and all glvalues designating part of
the deallocated storage become invalid glvalues (3.10
[basic.lval]). </ins>Indirection through an
invalid pointer value […]
</blockquote>
<p>3.8 [basic.life] ¶7:</p>
<blockquote class="std">Similarly, before the lifetime of an object has
started but after the storage which the object will occupy has been
allocated or, after the lifetime of an object has ended and before the
storage which the object
occupied is reused or released, any glvalue that refers to the original
object <ins>is an assigned storage glvalue and</ins> may be used but only in limited ways. For an object under construction or destruction, see 12.7. <del>Otherwise, such a glvalue refers to
allocated storage (3.7.4.2), and using the</del> <ins>Using </ins> properties of <del>the</del> <ins>an assigned storage</ins> glvalue that do not depend on its value is well-defined.
</blockquote>
<p>3.8 [basic.life] ¶8:</p>
<p>
</p>
<blockquote class="std">If, after the lifetime of an object has ended
and before the storage which the object occupied is reused or released,
a new object is created at the storage location which the original
object occupied,
a pointer that pointed to the original object, a<ins>n assigned storage</ins> reference that referred to the original object, or the name of the original object will automatically refer to the new object
<ins>(that is, become a pointer to that object, an assigned object reference and an assigned object lvalue, respectively)</ins>
and, once the lifetime of the new object has started, can be used to manipulate the new object, if:<br>
</blockquote>
<p>Append after 3.10 [basic.lval] ¶1 a paragraph ¶2:</p>
<blockquote class="std">
<ul>
<li>A <em>glvalue</em> …
</li>
<li>A <em>prvalue</em> …
</li>
<li>An <em>xvalue</em> is a glvalue that <ins>generally</ins> denotes an object or bit-field whose resources can be reused (usually
because it is near the end of its lifetime). [ <em>Example</em>: Certain kinds of expressions involving rvalue
references (8.3.2) yield xvalues, such as a call to a function whose return type is an rvalue reference or
a cast to an rvalue reference type. — <em>end example</em> ] <ins>[<em>Note:</em>
an xvalue cannot be null or past the end of an object, because
the only way to obtain such an xvalue would bind an unassigned lvalue
to a
reference via
a cast, which has undefined behavior (8.3.2 [dcl.ref]). — <em>end note</em>]</ins>
</li>
<li>
An <em>lvalue</em> is a glvalue that is not an xvalue.
<ins>
It is one of the following:
<ul>
<li>an assigned lvalue (see below), </li>
<li>a <em>null lvalue</em> (5.3.1 [expr.unary.op]), or</li>
<li>an <em>lvalue past the end of</em> an object (5.3.1
[expr.unary.op]), or
</li>
<li>an invalid lvalue (see below).</li>
</ul>
</ins>
</li>
<li>An <em>rvalue</em> …</li>
</ul>
[ <em>Note</em>: Historically, lvalues and rvalues were so-called because they could appear on the left- and right-hand
side of an assignment (although this is no longer generally true); glvalues are “generalized” lvalues, prvalues
are “pure” rvalues, and xvalues are “eXpiring” lvalues. Despite their names, these terms classify expressions,
not values<del>.</del><ins>; the latter is covered by the expression's assignment category.</ins> — <em>end note</em> ]
<ins>
An expression is <em>assigned</em> if it designates
<ul>
<li>a function, in which case it is an <em>assigned function</em>
expression, or
</li>
<li>an object during construction or destruction (12.7
[class.cdtor]) or an object or bitfield within its lifetime (3.8 [basic.life]), in which case
it is an <em>assigned object</em> expression, or
</li>
<li>an allocated region of storage (possibly occupied by an object), in which case it is an <em>assigned
storage</em> expression. [<em>Note</em>:
there can't be any glvalues referring to the memory occupied by a
destroyed bit-field, because binding a reference to a bit-field is
ill-formed, and accessing a member of an object that isn't alive is
undefined. That is, any glvalue referring to a bit-field is an assigned
object glvalue. — <em>end note</em>]<br>
</li>
</ul>
A prvalue is never assigned.
An <em>invalid</em> expression is one that referred to an object or
region of storage that has been deallocated (3.7 [basic.stc]). Using a
glvalue that is not assigned in a context where the language expects an
assigned glvalue has undefined behavior.
</ins>
<br>
<br>
Every expression belongs to exactly one of the fundamental
classifications in this taxonomy: lvalue, xvalue,
or prvalue. This property of an expression is called its <em>value
category</em>. <ins>Additionally, every expression belongs to exactly
one of the classifications listed above:
null expression (lvalues only), expression past the end of an object
(lvalues only), assigned function expression (lvalues only), assigned
object expression, assigned storage expression (glvalues only), or
invalid expression (glvalues only). This runtime property
of an expression is called its <em>assignment category</em>.</ins>
[<em>Note</em>: … — <em>end note</em> ]
</blockquote>
4.1 [conv.lval]:<br>
<blockquote class="std">
A glvalue (3.10) of a non-function, non-array type <tt>T</tt> can be converted to a prvalue. If <tt>T</tt> is an incomplete type, a program that necessitates this conversion is ill-formed. <ins>If the glvalue is not an assigned object glvalue, the behavior is undefined.</ins> […]
</blockquote>
<br>
4.2 [conv.array]:
<blockquote class="std">An lvalue or rvalue of type “array of <tt>N T</tt>”
or “array of unknown bound of <tt>T</tt>” can be converted to a
prvalue of
type “pointer to <tt>T</tt>”. <ins>If the expression refers to an
array,</ins>
the result is a pointer to the first element of <del>the</del><ins>that</ins>
array. <ins>If the expression is a null lvalue, the result is the null
pointer
value. If the expression is an lvalue past the end of an object, the
result is a
pointer past the end of the object. Otherwise, the behavior is
undefined.<br>
</ins>
</blockquote>
<p>4.3 [conv.func]:</p>
<blockquote class="std"> An lvalue of function type <tt>T</tt> can be
converted to a prvalue of type “pointer to <tt>T</tt>”. <ins>If the
lvalue is an assigned function lvalue,</ins> the result is a pointer to
the
function. <ins>If the lvalue is a null lvalue, the result is the null
pointer value. Otherwise, the behavior is undefined.</ins>
</blockquote>
<p>5.2.5 [expr.ref] ¶4:</p>
<blockquote class="std">
If <tt>E2</tt> is declared to have type
“reference to T”, then <tt>E1.E2</tt> is an lvalue; the type of <tt>E1.E2</tt>
is <tt>T</tt>. Otherwise,
one of the following rules applies.
<ul>
<li>If <tt>E2</tt> is a static data member […]</li>
<li>If <tt>E2</tt> is a non-static data member<ins>,
the behavior
is undefined if <tt>E1</tt> is not an assigned object expression.
If</ins> <del>and</del> the type of <tt>E1</tt> is “<em>cq1 vq1</em> <tt>X</tt>”,
and the type of <tt>E2</tt> is “<em>cq2 vq2</em> <tt>T</tt>”, […]
</li>
<li>If <tt>E2</tt> is a (possibly overloaded)
member function<ins>,
the behavior is undefined if <tt>E1</tt> is not an assigned object expression. </ins>
Function overload resolution (13.3) is used […]
</li>
</ul>
</blockquote>
<p>
5.2.8 [expr.typeid] ¶2:
</p>
<blockquote class="std">When <tt>typeid</tt> is applied to a<ins>n
assigned object</ins> glvalue expression
whose type is a polymorphic class type (10.3), the result refers to a <tt>std::type_info</tt>
object representing the type of the most derived object (1.8) (that is,
the dynamic type) to which the glvalue refers. If the glvalue
expression is <del>obtained by
applying the unary <tt>*</tt> operator to a pointer<sup>71</sup> and
the pointer is a null pointer value (4.10)</del> <ins>a null lvalue
(5.3.1 [expr.unary.op])</ins>, the <tt>typeid</tt> expression throws
an exception (15.1 [except.throw]) of a type that would match a handler
of type <tt>std::bad_typeid</tt> exception (18.7.4 [bad.typeid]). <br>
</blockquote>
<p>5.3.1 [expr.unary.op] ¶1:</p>
<blockquote class="std"> The unary <tt>*</tt> operator performs
indirection: the expression to which it is applied shall be a pointer
to an object <ins>or function</ins> type <ins><tt>T</tt></ins><ins>.</ins><del>,
or a pointer to a function type and the</del> <ins>The </ins>
result is an lvalue <ins>of type <tt>T</tt>:</ins><del>
referring to the object or function to which the expression points.</del> <ins><ul>
<li>if the pointer is the null pointer value, the result
is a null lvalue; otherwise, </li>
<li>if the pointer is past the end of an object, the result is an lvalue past
the end of that object; otherwise,</li>
<li>if the pointer points to an object or function,
the result is an assigned object lvalue or assigned function lvalue,
respectively, referring to that entity; otherwise, </li>
<li>if the pointer represents the
address of allocated storage, the result is an assigned storage lvalue
designating that region of storage.</li>
</ul>
Otherwise, the
behavior is undefined.</ins> [<em>Note</em>: … —<em>end note</em>]
</blockquote>
5.3.1 [expr.unary.op] ¶3:
<blockquote class="std"> The result of the unary <tt>&</tt>
operator is a pointer to its operand. The operand shall be an lvalue or
a <em>qualified-id</em>.
If the operand is a <em>qualified-id</em> naming a non-static or
variant member <tt>m</tt> of some class <tt>C</tt> with type <tt>T</tt>,
the
result has type “pointer to member of class <tt>C</tt> of type <tt>T</tt>”
and is a prvalue designating <tt>C::m</tt>. Otherwise, if
the type of the expression is <tt>T</tt>, the result has type “pointer
to <tt>T</tt>” and is a prvalue <del>that is the address of the
designated object (1.7) or a pointer to the designated function</del><ins>
pointer. <ins>The assignment category is determined as follows:
<ul>
<li>if the lvalue is an assigned object lvalue or assigned function lvalue,
the result points to the designated object or function, respectively; otherwise,</li>
<li>if the lvalue is an assigned storage
lvalue, the result represents the address of the designated region of
storage; otherwise,</li>
<li>if the lvalue is a null lvalue, the result is the null pointer value; otherwise,</li>
<li>if the lvalue is past the end of an object, the result is a pointer
past the end of that object.</li>
</ul>
Otherwise, the behavior is undefined</ins>.
</blockquote>
<p>5.18 [expr.ass] ¶8:</p>
<blockquote class="std">The assignment operator (<tt>=</tt>) and the
compound assignment operators all group right-to-left. All require a
modifiable lvalue as their left operand and return an lvalue referring
to the left operand<ins>; the behavior is undefined if the lvalue is
not an assigned object lvalue, or is an assigned storage lvalue member
access expression (5.2.5 [expr.ref]) designating a variant member (see
below)</ins>. The result in all cases is a bit-field if the left
operand is a bit-field. In all cases, the assignment is sequenced after
the value computation of the right and left operands, and before the
value computation of the assignment expression.<br>
</blockquote>
<p>8.3.2 [dcl.ref] ¶5: </p>
<blockquote class="std">
[…] <del>A reference shall be initialized to
refer to a valid object or function.</del> <ins>A
reference's name shall not be potentially evaluated (3.2 [odr.def]) in
its intializer. If the expression to which a reference is directly
bound
is
not an assigned expression designating either a function of an
appropriate
type (8.5.3 [dcl.init.ref]), or a region of storage of suitable size
and alignment to contain an object of the referenced type (3.8
[basic.life]), or an object residing in such storage, the behavior is
undefined. If a reference is initialized to refer to the virtual base
of its initializer, and its initializer is not an assigned object
expression, the behavior is undefined. </ins>[ <em>Note</em>:
in particular, a null reference cannot exist in a well-defined program,
because the only way to create such a reference would be to bind it to
<del>the “object”</del> <ins>a null lvalue</ins><del>obtained by indirection through a null pointer</del>,
which causes undefined
behavior. <ins>— <em>end note</em>] [<em>Note</em>: </ins>as
described in
9.6 [class.bit], a reference cannot be bound directly to a bit-field. <em>—
end note</em> ]
<ins>
[<em>Example:</em>
<pre class="example">int& i = true? 0 : i; // Error: i is potentially evaluated<br><br>int& j = *(int*)nullptr; // Undefined behavior: Binding a reference to a null lvalue</pre>
<em>— end example</em><ins>] Any use of a reference before it is
initialized results in undefined
behavior. [</ins><em>Example</em>:
<pre class="example">extern int& ir2;<br>int ir1 = ir2; // Undefined behavior: ir2 not yet initialized<br></pre>
<em>— end example</em>]
</ins>
</blockquote>
<ins></ins>
<p>Create 8.3.2 [dcl.ref] ¶8:<br></p>
<blockquote class="stdins">
The assignment category (3.10 [basic.lval]) of a reference's name is called the reference's assignment category:
<em>assigned function</em> reference, <em>assigned object</em> reference, <em>assigned storage</em> reference and <em>invalid reference</em>.
As described above, if a reference is initialized to be an invalid reference, the
behavior is undefined.
After initialization, the reference has the same type of assignment category as
the expression it was directly bound to. [<em>Note</em>: a reference's assignment category
changes in the following situations:
<ul>
<li>The reference is an assigned object reference and the
designated object is destroyed. The reference becomes an assigned
storage reference, provided the storage occupied by the original object
has not
simultaneously been deallocated. <br>
</li>
<li>The reference is an
assigned object or assigned storage reference, and the storage occupied
by the object or the designated storage, respectively, is deallocated.
The reference becomes an invalid reference.
</li>
<li>The reference is an
assigned storage reference and a new object of the same cv-unqualified
type is created in the same storage; under certain circumstances, the
reference becomes an assigned object reference.
</li>
</ul>
— <em>end note</em>]
[ <em>Example: </em>
<pre class="example">
int const& f() {
int const& i = 0; // i is an assigned object reference
return i;
}
auto&& r = f(); // Undefined behavior: the reference can never be used as a non-invalid reference
</pre>
— <em>end example</em>]
</blockquote>
<h3>References</h3>
<p>[<a id="CWG232">CWG232</a>] “Is indirection through a null pointer
undefined behavior?“: <a href="http://wg21.link/cwg232">wg21.link/cwg232</a>
</p>
<p>[<a id="CWG453">CWG453</a>] “References may only bind to “valid”
objects“: <a href="http://wg21.link/cwg453">wg21.link/cwg453</a>
</p>
<p>[<a id="CWG504">CWG504</a>] “Should use of a variable in its own
initializer require a diagnostic?“:
<a href="http://wg21.link/cwg504">wg21.link/cwg504</a>
</p>
<p>[<a id="P0137R0">P0137R1</a>] (Richard Smith) “Core Issue 1776:
Replacement of class objects containing reference members“: <a href="http://wg21.link/P0137R0">wg21.link/P0137R1</a>
</p>
<p>[<a id="UB504">UB504</a>] “[ub] Proposal: make self-initialized
references
ill-formed (C++17?) ” <a href="http://www.open-std.org/pipermail/ub/2014-September/000506.html">open-std.org/pipermail/ub/2014-September/000506.html</a>
</p>
</body>
</html>