[Moved to DR at the October, 2012 meeting.]

Proposed resolution (February, 2012):

1. Change 6.7.6.5.2 [basic.stc.dynamic.allocation] paragraph 2 as follows:

...The effect of dereferencing indirecting through a pointer returned as a request for zero size is undefined.

2. Change _N4885_6.7.5.5.4 [basic.stc.dynamic.safety] paragraph 2 as follows:

• the value returned by a call to the C ++ standard library implementation of ::operator new(std:: size_t); [Footnote: This section does not impose restrictions on dereferencing indirection through pointers to memory not allocated by ::operator new. This maintains the ability of many C++ implementations to use binary libraries and components written in other languages. In particular, this applies to C binaries, because dereferencing indirection through pointers to memory allocated by std::malloc is not restricted. —end footnote]

• the result of taking the address of an object (or one of its subobjects) designated by an lvalue resulting from dereferencing indirection through a safely-derived pointer value;

• ...

3. Change 6.7.4 [basic.life] paragraph 5 as follows:

...Such Indirection through such a pointer may be dereferenced is permitted but the resulting lvalue may only be used in limited ways...

4. Change 7.3.13 [conv.mem] paragraph 2 as follows:

...Since the result has type “pointer to member of D of type cv T”, it can be dereferenced indirection through it with a D object is valid. The result is the same as if indirecting through the pointer to member of B were dereferenced with the B subobject of D. The null member pointer value...

5. Change 7.6.1.9 [expr.static.cast] paragraph 12 as follows:

...[Note: although class B need not contain the original member, the dynamic type of the object on with which indirection through the pointer to member is dereferenced performed must contain the original member; see 7.6.4 [expr.mptr.oper]. —end note]

6. Change 7.6.2.2 [expr.unary.op] paragraph 1 as follows:

...[Note: indirection through a pointer to an incomplete type (other than cv void) can be dereferenced is valid. The lvalue thus obtained...

7. Change 7.6.10 [expr.eq] paragraph 2 as follows:

...Otherwise they compare equal if and only if they would refer to the same member of the same most derived object (6.7.2 [intro.object]) or the same subobject if they were dereferenced indirection with a hypothetical object of the associated class type were performed. [Example:...

8. Change 9.11 [dcl.link] paragraph 8:

[Note: Because the language linkage is part of a function type, when indirecting through a pointer to C function (for example) is dereferenced, the function to which it the resulting lvalue refers is considered a C function. —end note]

9. Change 9.3.4.3 [dcl.ref] paragraph 5 as follows:

...[Note: 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 the “object” obtained by dereferencing indirection through a null pointer, which causes undefined behavior. As described...

10. Change 16.4.4.6 [allocator.requirements] table 27:

Variable	Definition
...
c	a dereferenceable pointer of type C* through which indirection is valid
...

11. Change 20.2.3.3 [pointer.traits.functions] as follows:

Returns: The first member function returns a dereferenceable pointer to r obtained by calling Ptr::pointer_to(r) through which indirection is valid; an instantiation of this function is ill-formed...

12. Change _N4885_.20.10.5 [util.dynamic.safety] paragraph 10 as follows:

Effects: The n bytes starting at p no longer contain traceable pointer locations, independent of their type. Hence pointers indirection through a pointer located there may not be dereferenced is undefined if the object they point it points to was created by global operator new and not previously declared reachable...

13. Change 26.11 [specialized.algorithms] paragraph 1 as follows:

...is required to have the property that no exceptions are thrown from increment, assignment, comparison, or dereference of indirection through valid iterators...

14. Change 28.3.4.6.2.3 [locale.time.get.virtuals] paragraph 11 as follows:

Requires: t shall be dereferenceable point to an object.

15. Change 23.4.3.2 [map.cons] paragraph 3 as follows:

Requires: If the iterator's dereference indirection operator returns an lvalue or a const rvalue pair<key_type, mapped_type>, then both key_type and mapped_type shall be CopyConstructible.

16. Change 23.4.4.2 [multimap.cons] paragraph 3 as follows:

Requires: If the iterator's dereference indirection operator returns an lvalue or a const rvalue pair<key_type, mapped_type>, then both key_type and mapped_type shall be CopyConstructible.

17. Change 23.4.6.2 [set.cons] paragraph 4 as follows:

Requires: If the iterator's dereference indirection operator returns an lvalue or a non-const rvalue, then Key shall be CopyConstructible.

18. Change 23.4.7.2 [multiset.cons] paragraph 3 as follows:

Requires: If the iterator's dereference indirection operator returns an lvalue or a const rvalue, then Key shall be CopyConstructible.

19. Change 24.5.4 [move.iterators] paragraph 1 as follows:

Class template move_iterator is an iterator adaptor with the same behavior as the underlying iterator except that its dereference indirection operator implicitly converts the value returned by the underlying iterator's dereference indirection operator to an rvalue reference...

20. Change the title of 28.6.11.1.4 [re.regiter.deref] as follows:

regex_iterator dereference indirection

21. Change the title of 28.6.11.2.4 [re.tokiter.deref] as follows:

regex_token_iterator dereference indirection

Notes from the August, 2011 meeting:

CWG prefers use of the term “indirection” instead of “dereferencing.” This would be consistent with the usage in the C Standard and would avoid entanglement with the C++ concept of a reference type.

Proposed resolution (December, 2006):

1. Change 7.6.2.2 [expr.unary.op] paragraph 1 as follows:

The unary * operator performs indirection dereferences a pointer value: the expression to which it is applied shall be a pointer...

2. Change 9.3.4.5 [dcl.array] paragraph 8 as follows:

The results are added and indirection applied values are added and the result is dereferenced to yield an array (of five integers), which in turn is converted to a pointer to the first of the integers.

3. Change 9.3.4.6 [dcl.fct] paragraph 9 as follows:

The binding of *fpi(int) is *(fpi(int)), so the declaration suggests, and the same construction in an expression requires, the calling of a function fpi, and then using indirection through dereferencing the (pointer) result to yield an integer. In the declarator (*pif)(const char*, const char*), the extra parentheses are necessary to indicate that indirection through dereferencing a pointer to a function yields a function, which is then called.

4. Change the index for * and “dereferencing” no longer to refer to “indirection.”

[Drafting note: 29.6.9 [template.indirect.array] requires no change. Many more places in the current wording use “dereferencing” than “indirection.”]

Split off from issue 315.

Incidentally, another thing that ought to be cleaned up is the inconsistent use of "indirection" and "dereference". We should pick one.