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] |
Daniel Berlin wrote: but if there's no exemption for character pointers in that case, there should be, at least in GNU C, where we assume unsegmented memory.
Daniel Berlin wrote:
I had this discussion at Apple with Geoff Keating and Mike Stump. When I left, they were on board with this. I would not have taken the time to do this if I thought I was bending the language. A never talked to Matt about this.
I'm sure Geoff and Mike will share their reasoning.
The dodgy bit to me seems to be the pointer arithmetic, since arithmetic on pointers is constrained to take place within a single array.
However, C99 6.3.2.3/8 says:
"When a pointer to an object is converted to a pointer to a character type, the result points to the lowest addressed byte of the object. Successive increments of the result, up to the size of the object, yield pointers to the remaining bytes of the object." So, that does say that we can portably implement memcpy by casting the object address to "const unsigned char *" and then stepping through the object.
Pedantically, this doesn't permit any other operation other than increments; it doesn't say that you can add two, or decrement after you increment, but disallowing those operations would be silly. I don't this it pays to read standards *that* pedantically.
That's still not quite enough to support validity of the code you posted, in that you were taking the address of a field in the object, not the entire object. But I think it is enough to support validity of:
struct S { int i; int j; };
void f(int *p) { p = (int *)((char *)p - offsetof (struct S, j)) *p = 3; }
void g() { S s; f ((int *) ((char*) &s + offsetof (struct S, j))); }
So, I think that the argument for invalidity has to hinge on the fact that "(int*)((char*) &s + offsetof (struct S, j)))" is different from "&s.j", even though the standard says those two expressions have the same type and the same value.
Attachment:
smime.p7s
Description: S/MIME cryptographic signature
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |