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.
Andrew.
