Hacker News new | past | comments | ask | show | jobs | submit login

> "an aggregate or union type that includes one of the aforementioned types among its members (including, recursively, a member of a subaggregate or contained union), or"

I don't think you're properly understanding this wording (which was there since 1989 ANSI C, IIRC).

Firstly, we can interpret it very poorly, so that this appears defined:

  { double x = 42.0;  /* declared type is double */
    struct foo { int y; double z; } *p = (struct foo *) &x;

    return p->y; }
Hey, x is being accessed via an aggregate type, and that type includes one of the aforementioned types (the declared type of x) as one of its members, namely member z!

Here is the real intent of the wording. Why it is necessary is simply because members are implicitly accessed when an aggregate is accessed as a whole. That is all! If we assign one "struct foo" to another, for instance, and that "struct foo" has a member "int x", that member is accessed and it is being accessed through an lvalue of type "struct foo". Without the above wording, that use would appear not to be conforming, because a "struct foo" type is being used to access an "int".

> In general, however, your complaint is basically: "C is not a pure structural type system, it's a name based one for the most part".

No, that isn't my complaint at all because, note that I still want a diagnostic if we remove the cast:

   // diagnosable constraint violation:
   struct foo *p = &struct_bar_instance;
I just want the access to be defined to members that happen to be of the same type and at the same offsets in these structures, without going all the way to assert that they are compatible types for the purposes of assignment/passing and pointer conversions.

The access should be defined even if the offset is the same in different ways, on those platforms where it happens to work out:

   struct foo { char c; int x; };
   struct bar { short s; int x; };
If c is one byte, s is two, and x is aligned to the next multiple of 4, so its offset is 4 in both structures, accessing x should work through either struct foo or struct bar on this implementation. I.e. it is undefined behavior if the offset isn't the same, otherwise requirements apply. Just like 1 << 30 is defined, and its value is the same, on all platforms where int is at least 32 bits wide. But it is not defined if int is, say, 16 bits (out of range shift).



"No, that isn't my complaint at all because, note that I still want a diagnostic if we remove the cast."

Okay, then you want something super strange and in-between :)

"I just want the access to be defined to members that happen to be of the same type and at the same offsets in these structures, without going all the way to assert that they are compatible types for the purposes of assignment/passing and pointer conversions. "

Okay ...

"The access should be defined even if the offset is the same in different ways, on those platforms where it happens to work out: "

This qualifies in my book as super-strange. I'm pretty sure you will find no one who views the standard this way, as it contradicts the explicit wording pretty directly :P.

So if you want that, you'd probably need a new language.

Note also that it makes actual pointer analysis (IE andersens, etc) impossible without complete and total target info.

You could never have a target independent thing do pointer analysis in this world.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: