Richard, et al.,
Any feedback on my comments below on what C/C++ allows? I'd like to just
be missing something ;)
Thanks again,
Hal
On 04/21/2017 06:03 AM, Hal Finkel via Phabricator wrote:
...
Our struct-path TBAA does the following:
struct X { int a, b; };
X x { 50, 100 };
X *o = (X*) (((int*) &x) + 1);
int a_is_b = o->a; // This is UB (or so we say)?
Because we assume that the (type, offset) tuples are identified entities in the
type-aliasing tree. Practically speaking, this certainly makes sense to me.
However, I don't see anything in the language that actually forbids this
behavior. In case it matters, because in the above case the type of the struct
actually matches, we similarly forbid:
struct X { int a, b; };
struct Y { int a; float b; };
X x { 50, 100 };
Y *o = (X*) (((int*) &x) + 1);
int a_is_b = o->a; // This is UB (or so we say)?
as is this:
struct X { int a, b; };
struct Y { int a; float b; X h; /* in case this matters for the aggregate
members thing */ };
X x { 50, 100 };
Y *o = (X*) (((int*) &x) + 1);
int a_is_b = o->a; // This is UB (or so we say)?
(although, as you say, this shouldn't matter in C++ because we don't have
struct glvalues)
In any case, am I missing something?
...
As I recall, "store can create an object" is the broad direction that SG12
agreed on for the cases where you have a pointer into a raw storage buffer (that is, a
char array), and we want the low-level storage allocation functions to give us such a
buffer.
What about a read after a calloc (or memset)?
https://reviews.llvm.org/D32199
--
Hal Finkel
Lead, Compiler Technology and Programming Languages
Leadership Computing Facility
Argonne National Laboratory
_______________________________________________
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
