This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: alias.c:nonoverlapping_component_refs_p


    No, but i would expect that if it was not true, it would be documented 
    somewhere.

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.
    Ada does.
    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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]