This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: GCC aliasing rules: more aggressive than C99?
On Thu, Jan 7, 2010 at 12:29 PM, Andrew Haley <aph@redhat.com> wrote:
> On 01/06/2010 07:24 PM, Joshua Haberman wrote:
>
>> In the notes that Nick referenced it says:
>>
>> ? Is there ?anybody that thinks the rules are clear enough? ?No one is
>> ? really able to interpret them. ?So it seems that they are not
>> ? clear enough. ?The problem is how to state them.
>>
>> ? [...]
>>
>> ? ACTION: Clark to work on a clearer formulation of what the rules are,
>> ? re: N1409.
>>
>> So it wounds like Clark is already working on this. ?We should just write
>> to him and point him to this thread. ?I can do this.
>>
>> With regard to a clearer way to state the rules: I think the rules would
>> be easier to understand if the normative part only addressed the ways in
>> which object aliases could be *created*. ?For example, the rules could
>> state that:
>>
>> ? struct A { int x; } a;
>> ? int *pi = &a.x;
>>
>> ...is a valid way to create an int* that aliases a struct member, whereas:
>>
>> ? int i;
>> ? struct A { int x; } *a = (struct u*)&i;
>>
>> ...is not.
>
> The response I think you may get is that this is already settled.
> I've seen this same argument many times (in mailing lists and in
> comp.lang.c) over the last decade or so, and the result has always
> been the same.
But I still can't find proper language in the standard that restricts
pointer dereference nor pointer conversion (apart from the alignment
issue, but that's only where it constraints bijectivity of pointer conversion).
Richard.