Subject: Re: [ub] type punning through congruent base class?
From: Gabriel Dos Reis (gdr_at_[hidden])
Date: 2014-01-17 17:19:38
| From what I've learned in this thread, the (rough) intended C++ model for
| PODs (assuming memory of the right size/alignment) would seem to be "the
| lifetime of a B starts when you write to the memory as a B, and ends when you
| free the memory or write to the memory as different type." [Disclaimer: I'm
| not sure if "read from the memory as a B" also starts lifetime."]
that would be close to what C does with effective types.
| I think we can do better,
| but it seems like that's the (rough) intent of the
| status quo, leaving aside the question of whether the wording actually says
| *If* that is the (rough) intent, then in:
| void *p = malloc(sizeof(B)); // 1
| B* pb = (B*)p; // 2
| pb->i = 0; // 3
| short* ps = (short*)p; // 4
| *ps = 0; // 5
| free(p); // 6
| I assume that the reasoning would be that:
| * line 3 starts the lifetime of a B (we're writing to the bits of a B member,
| not just any int)
line 3 does not write as a B, so it wouldn't count -- just like in C.
| * line 5 ends the lifetime of that B and begins the lifetime of a short
| * line 6 ends the lifetime of that short
| Again ignoring whether this is desirable, is that (roughly) the intent of the
| current wording?
Almost: we never started the lifetime of a B object.
| If yes, does the wording express it (a) accurately and (b) clearly?
My understanding is "no" for both.
| Finally, regardless of the above answer, do we want to change anything about
| the legality or semantics of the above type-punning code, such as possibly
| having a "type-safe mode" where such code is somehow not allowed unless in
| an "extern "C-compat"" block or something?
This is a good question! Which definitely needs a paper :-)
My view is that if the storage isn't declared or accessed as a B, then it isn't a B .
And this is compatible with the C's standards.
SG12 list run by herb.sutter at gmail.com