[intro.memory] Implication of the note for implementation-managed "memory locations"

[frederick-vs-ja]

Currently a note in [intro.memory] (originally introduced by N2429) says:

[Note 2: Various features of the language, such as references and virtual functions, might involve additional memory locations that are not accessible to programs but are managed by the implementation. — end note]

This note seemingly implies that such underlying implementation details are scalar objects or bit-field sequences (per the definition of memory location).

Such implication looks weird despite not being actual overspecification. If this note is considered not really helpful (because such a "memory location" isn't supposed to be observable, perhaps), I guess we should remove it.

[jensmaurer]

Well, the real question is if those hidden memory locations can participate in data races. I think the note wants to say "yes".

[frederick-vs-ja]

Well, the real question is if those hidden memory locations can participate in data races. I think the note wants to say "yes".

I think the answer should be "yes" too.

However, the standard wording doesn't recognize any operation as reading or modification of such memory locations, even if the operation is undefined and/or does modify some implemention-managed memory location in the view of the implementation. So I still wonder whether it's helpful to attempt to harmonize the meanings of memory location of the standard and implementations, given when the affected memory regions are implementation-controlled, an implementation may (and possibly need to) consider more cases to be conflicting.