From Jason Turner

[basic.stc]

Diff to HTML by rtfpessoa

Files changed (1) hide show
  1. tmp/tmp08hkve45/{from.md → to.md} +53 -42
tmp/tmp08hkve45/{from.md → to.md} RENAMED
@@ -88,12 +88,14 @@ implicitly declared in global scope in each translation unit of a
88
  program.
89
 
90
  ``` cpp
91
  void* operator new(std::size_t);
92
  void* operator new[](std::size_t);
93
- void operator delete(void*);
94
- void operator delete[](void*);
 
 
95
  ```
96
 
97
  These implicit declarations introduce only the function names `operator`
98
  `new`, `operator` `new[]`, `operator` `delete`, and `operator`
99
  `delete[]`. The implicit declarations do not introduce the names `std`,
@@ -139,64 +141,70 @@ storage allocated (until the storage is explicitly deallocated by a call
139
  to a corresponding deallocation function). Even if the size of the space
140
  requested is zero, the request can fail. If the request succeeds, the
141
  value returned shall be a non-null pointer value ([[conv.ptr]]) `p0`
142
  different from any previously returned value `p1`, unless that value
143
  `p1` was subsequently passed to an `operator` `delete`. The effect of
144
- dereferencing a pointer returned as a request for zero size is
145
- undefined.[^11]
146
 
147
  An allocation function that fails to allocate storage can invoke the
148
  currently installed new-handler function ([[new.handler]]), if any. A
149
  program-supplied allocation function can obtain the address of the
150
  currently installed `new_handler` using the `std::get_new_handler`
151
  function ([[set.new.handler]]). If an allocation function declared with
152
  a non-throwing *exception-specification* ([[except.spec]]) fails to
153
  allocate storage, it shall return a null pointer. Any other allocation
154
  function that fails to allocate storage shall indicate failure only by
155
- throwing an exception of a type that would match a handler (
156
- [[except.handle]]) of type `std::bad_alloc` ([[bad.alloc]]).
157
 
158
  A global allocation function is only called as the result of a new
159
  expression ([[expr.new]]), or called directly using the function call
160
  syntax ([[expr.call]]), or called indirectly through calls to the
161
  functions in the C++standard library. In particular, a global allocation
162
  function is not called to allocate storage for objects with static
163
  storage duration ([[basic.stc.static]]), for objects or references with
164
  thread storage duration ([[basic.stc.thread]]), for objects of type
165
- `std::type_info` ([[expr.typeid]]), or for the copy of an object thrown
166
- by a `throw` expression ([[except.throw]]).
167
 
168
  #### Deallocation functions <a id="basic.stc.dynamic.deallocation">[[basic.stc.dynamic.deallocation]]</a>
169
 
170
  Deallocation functions shall be class member functions or global
171
  functions; a program is ill-formed if deallocation functions are
172
  declared in a namespace scope other than global scope or declared static
173
  in global scope.
174
 
175
  Each deallocation function shall return `void` and its first parameter
176
  shall be `void*`. A deallocation function can have more than one
177
- parameter. If a class `T` has a member deallocation function named
178
- `operator` `delete` with exactly one parameter, then that function is a
179
- usual (non-placement) deallocation function. If class `T` does not
180
- declare such an `operator` `delete` but does declare a member
181
- deallocation function named `operator` `delete` with exactly two
182
- parameters, the second of which has type `std::size_t` (
183
- [[support.types]]), then this function is a usual deallocation function.
184
- Similarly, if a class `T` has a member deallocation function named
185
- `operator` `delete[]` with exactly one parameter, then that function is
186
- a usual (non-placement) deallocation function. If class `T` does not
187
- declare such an `operator` `delete[]` but does declare a member
188
- deallocation function named `operator` `delete[]` with exactly two
189
- parameters, the second of which has type `std::size_t`, then this
190
- function is a usual deallocation function. A deallocation function can
191
- be an instance of a function template. Neither the first parameter nor
192
- the return type shall depend on a template parameter. That is, a
193
- deallocation function template shall have a first parameter of type
194
- `void*` and a return type of `void` (as specified above). A deallocation
195
- function template shall have two or more function parameters. A template
196
- instance is never a usual deallocation function, regardless of its
197
- signature.
 
 
 
 
 
 
198
 
199
  If a deallocation function terminates by throwing an exception, the
200
  behavior is undefined. The value of the first argument supplied to a
201
  deallocation function may be a null pointer value; if so, and if the
202
  deallocation function is one supplied in the standard library, the call
@@ -212,31 +220,34 @@ invocation of either `operator` `new[](std::size_t)` or `operator`
212
 
213
  If the argument given to a deallocation function in the standard library
214
  is a pointer that is not the null pointer value ([[conv.ptr]]), the
215
  deallocation function shall deallocate the storage referenced by the
216
  pointer, rendering invalid all pointers referring to any part of the
217
- *deallocated storage*. The effect of using an invalid pointer value
218
- (including passing it to a deallocation function) is undefined.[^12]
 
 
219
 
220
  #### Safely-derived pointers <a id="basic.stc.dynamic.safety">[[basic.stc.dynamic.safety]]</a>
221
 
222
  A *traceable pointer object* is
223
 
224
  - an object of an object pointer type ([[basic.compound]]), or
225
  - an object of an integral type that is at least as large as
226
  `std::intptr_t`, or
227
- - a sequence of elements in an array of character type, where the size
228
- and alignment of the sequence match those of some object pointer type.
 
229
 
230
  A pointer value is a *safely-derived pointer* to a dynamic object only
231
  if it has an object pointer type and it is one of the following:
232
 
233
  - the value returned by a call to the C++standard library implementation
234
- of `::operator new(std::size_t)`;[^13]
235
  - the result of taking the address of an object (or one of its
236
- subobjects) designated by an lvalue resulting from dereferencing a
237
- safely-derived pointer value;
238
  - the result of well-defined pointer arithmetic ([[expr.add]]) using a
239
  safely-derived pointer value;
240
  - the result of a well-defined pointer conversion ([[conv.ptr]], 
241
  [[expr.cast]]) of a safely-derived pointer value;
242
  - the result of a `reinterpret_cast` of a safely-derived pointer value;
@@ -263,16 +274,16 @@ at least as large as `std::intptr_t` and it is one of the following:
263
  `reinterpret_cast<void*>(P)`.
264
 
265
  An implementation may have *relaxed pointer safety*, in which case the
266
  validity of a pointer value does not depend on whether it is a
267
  safely-derived pointer value. Alternatively, an implementation may have
268
- *strict pointer safety*, in which case a pointer value that is not a
269
- safely-derived pointer value is an invalid pointer value unless the
270
- referenced complete object is of dynamic storage duration and has
271
- previously been declared reachable ([[util.dynamic.safety]]). the
272
- effect of using an invalid pointer value (including passing it to a
273
- deallocation function) is undefined, see 
274
  [[basic.stc.dynamic.deallocation]]. This is true even if the
275
  unsafely-derived pointer value might compare equal to some
276
  safely-derived pointer value. It is implementation defined whether an
277
  implementation has relaxed or strict pointer safety.
278
 
 
88
  program.
89
 
90
  ``` cpp
91
  void* operator new(std::size_t);
92
  void* operator new[](std::size_t);
93
+ void operator delete(void*) noexcept;
94
+ void operator delete[](void*) noexcept;
95
+ void operator delete(void*, std::size_t) noexcept;
96
+ void operator delete[](void*, std::size_t) noexcept;
97
  ```
98
 
99
  These implicit declarations introduce only the function names `operator`
100
  `new`, `operator` `new[]`, `operator` `delete`, and `operator`
101
  `delete[]`. The implicit declarations do not introduce the names `std`,
 
141
  to a corresponding deallocation function). Even if the size of the space
142
  requested is zero, the request can fail. If the request succeeds, the
143
  value returned shall be a non-null pointer value ([[conv.ptr]]) `p0`
144
  different from any previously returned value `p1`, unless that value
145
  `p1` was subsequently passed to an `operator` `delete`. The effect of
146
+ indirecting through a pointer returned as a request for zero size is
147
+ undefined.[^12]
148
 
149
  An allocation function that fails to allocate storage can invoke the
150
  currently installed new-handler function ([[new.handler]]), if any. A
151
  program-supplied allocation function can obtain the address of the
152
  currently installed `new_handler` using the `std::get_new_handler`
153
  function ([[set.new.handler]]). If an allocation function declared with
154
  a non-throwing *exception-specification* ([[except.spec]]) fails to
155
  allocate storage, it shall return a null pointer. Any other allocation
156
  function that fails to allocate storage shall indicate failure only by
157
+ throwing an exception ([[except.throw]]) of a type that would match a
158
+ handler ([[except.handle]]) of type `std::bad_alloc` ([[bad.alloc]]).
159
 
160
  A global allocation function is only called as the result of a new
161
  expression ([[expr.new]]), or called directly using the function call
162
  syntax ([[expr.call]]), or called indirectly through calls to the
163
  functions in the C++standard library. In particular, a global allocation
164
  function is not called to allocate storage for objects with static
165
  storage duration ([[basic.stc.static]]), for objects or references with
166
  thread storage duration ([[basic.stc.thread]]), for objects of type
167
+ `std::type_info` ([[expr.typeid]]), or for an exception object (
168
+ [[except.throw]]).
169
 
170
  #### Deallocation functions <a id="basic.stc.dynamic.deallocation">[[basic.stc.dynamic.deallocation]]</a>
171
 
172
  Deallocation functions shall be class member functions or global
173
  functions; a program is ill-formed if deallocation functions are
174
  declared in a namespace scope other than global scope or declared static
175
  in global scope.
176
 
177
  Each deallocation function shall return `void` and its first parameter
178
  shall be `void*`. A deallocation function can have more than one
179
+ parameter. The global `operator delete` with exactly one parameter is a
180
+ usual (non-placement) deallocation function. The global
181
+ `operator delete` with exactly two parameters, the second of which has
182
+ type `std::size_t`, is a usual deallocation function. Similarly, the
183
+ global `operator delete[]` with exactly one parameter is a usual
184
+ deallocation function. The global `operator delete[]` with exactly two
185
+ parameters, the second of which has type `std::size_t`, is a usual
186
+ deallocation function.[^13] If a class `T` has a member deallocation
187
+ function named `operator` `delete` with exactly one parameter, then that
188
+ function is a usual deallocation function. If class `T` does not declare
189
+ such an `operator` `delete` but does declare a member deallocation
190
+ function named `operator` `delete` with exactly two parameters, the
191
+ second of which has type `std::size_t`, then this function is a usual
192
+ deallocation function. Similarly, if a class `T` has a member
193
+ deallocation function named `operator` `delete[]` with exactly one
194
+ parameter, then that function is a usual (non-placement) deallocation
195
+ function. If class `T` does not declare such an `operator` `delete[]`
196
+ but does declare a member deallocation function named `operator`
197
+ `delete[]` with exactly two parameters, the second of which has type
198
+ `std::size_t`, then this function is a usual deallocation function. A
199
+ deallocation function can be an instance of a function template. Neither
200
+ the first parameter nor the return type shall depend on a template
201
+ parameter. That is, a deallocation function template shall have a first
202
+ parameter of type `void*` and a return type of `void` (as specified
203
+ above). A deallocation function template shall have two or more function
204
+ parameters. A template instance is never a usual deallocation function,
205
+ regardless of its signature.
206
 
207
  If a deallocation function terminates by throwing an exception, the
208
  behavior is undefined. The value of the first argument supplied to a
209
  deallocation function may be a null pointer value; if so, and if the
210
  deallocation function is one supplied in the standard library, the call
 
220
 
221
  If the argument given to a deallocation function in the standard library
222
  is a pointer that is not the null pointer value ([[conv.ptr]]), the
223
  deallocation function shall deallocate the storage referenced by the
224
  pointer, rendering invalid all pointers referring to any part of the
225
+ deallocated storage. Indirection through an invalid pointer value and
226
+ passing an invalid pointer value to a deallocation function have
227
+ undefined behavior. Any other use of an invalid pointer value has
228
+ implementation-defined behavior.[^14]
229
 
230
  #### Safely-derived pointers <a id="basic.stc.dynamic.safety">[[basic.stc.dynamic.safety]]</a>
231
 
232
  A *traceable pointer object* is
233
 
234
  - an object of an object pointer type ([[basic.compound]]), or
235
  - an object of an integral type that is at least as large as
236
  `std::intptr_t`, or
237
+ - a sequence of elements in an array of narrow character type (
238
+ [[basic.fundamental]]), where the size and alignment of the sequence
239
+ match those of some object pointer type.
240
 
241
  A pointer value is a *safely-derived pointer* to a dynamic object only
242
  if it has an object pointer type and it is one of the following:
243
 
244
  - the value returned by a call to the C++standard library implementation
245
+ of `::operator new(std::size_t)`;[^15]
246
  - the result of taking the address of an object (or one of its
247
+ subobjects) designated by an lvalue resulting from indirection through
248
+ a safely-derived pointer value;
249
  - the result of well-defined pointer arithmetic ([[expr.add]]) using a
250
  safely-derived pointer value;
251
  - the result of a well-defined pointer conversion ([[conv.ptr]], 
252
  [[expr.cast]]) of a safely-derived pointer value;
253
  - the result of a `reinterpret_cast` of a safely-derived pointer value;
 
274
  `reinterpret_cast<void*>(P)`.
275
 
276
  An implementation may have *relaxed pointer safety*, in which case the
277
  validity of a pointer value does not depend on whether it is a
278
  safely-derived pointer value. Alternatively, an implementation may have
279
+ *strict pointer safety*, in which case a pointer value referring to an
280
+ object with dynamic storage duration that is not a safely-derived
281
+ pointer value is an invalid pointer value unless the referenced complete
282
+ object has previously been declared reachable (
283
+ [[util.dynamic.safety]]). the effect of using an invalid pointer value
284
+ (including passing it to a deallocation function) is undefined, see 
285
  [[basic.stc.dynamic.deallocation]]. This is true even if the
286
  unsafely-derived pointer value might compare equal to some
287
  safely-derived pointer value. It is implementation defined whether an
288
  implementation has relaxed or strict pointer safety.
289