This is the mail archive of the
mailing list for the GCC project.
- From: kenner at vlsi1 dot ultra dot nyu dot edu (Richard Kenner)
- To: dan at cgsoftware dot com
- Cc: gcc-patches at gcc dot gnu dot org
- Date: Mon, 3 Dec 01 09:33:23 EST
- Subject: Re: alias.c:nonoverlapping_component_refs_p
No, but i would expect that if it was not true, it would be documented
Why? As I say, we don't document all the possible things that *aren't*
true, since that's an infinite set. Instead, we document those things
that *are* true. If it's not documented as true, you can't rely on it.
If it changed the way things are, or valid assumptions you can make, it
should be documented that the possible semantics have changed.
There was no change. Ther was *never* any implication or code that assumed
that fields did not overlap until yesterday.
No front end before Ada allowed fields that overlapped.
Therefore, there needs to be something saying that record_type is now
allowed to have fields that overlap.
It was *always* allowed to have fields that overlap. Do you know that they
never do for C++. I don't know either way.
> One could, but I don't think it would add much. Until now, no code has
> been written that assumed fields don't overlap.
However, the documentation that *does* exist implies they don't.
Only if you interpret it in a way in which it was not intended to
be interpreted. The type nodes were *never* intended to precisely match
C semantics, but to be extensions of those semantics. Over time, more and
more of those extensions have been used, but that does *not* represent a
change in specification.