Re: [PATCH][2.6.6-rc3] gcc-3.4.0 fixes

[William Lee Irwin III]

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@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/