Messages in this thread | | | Date | Tue, 1 Jun 2004 08:09:13 -0700 | From | William Lee Irwin III <> | Subject | Re: [PATCH][2.6.6-rc3] gcc-3.4.0 fixes |
| |
On Tue, Jun 01, 2004 at 04:52:59PM +0200, Mikael Pettersson wrote: > You're assuming pointers have uniform representation. > C makes no such guarantees, and machines _have_ had > different types of representations in the past. > Some not-so-obsolete 64-bit machines in effect use fat > representations for pointers to functions (descriptors), > but they usually cheat and use pointers to the descriptors > instead. However, a C implementation could legally > represent a function pointer as a 128-bit value, while > data pointers remain 64 bits.
IIRC for all types foo, sizeof(foo *) <= sizeof(void *), no? If so, 128-bit function pointers implies >= 128-bit void pointers.
On Tue, Jun 01, 2004 at 04:52:59PM +0200, Mikael Pettersson wrote: > A cast fundamentally involves an assignment conversion, > a copy to a temporary, and it yields an rvalue. > Even if we allow its use as an lvalue, the semantics > would still be to assign the copy not the original. > So cast-as-lvalue as gcc implemented it changed two > major aspects of the semantics. Call me conservative > if you like, but that's simply not C any more.
Oh, yeah, lvalue casting is degenerate filth.
-- wli - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |