[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Tinycc-devel] Fun little bug...
From: |
Dave Dodge |
Subject: |
Re: [Tinycc-devel] Fun little bug... |
Date: |
Wed, 5 Sep 2007 02:30:56 -0400 |
User-agent: |
Mutt/1.5.13 (2006-08-11) |
On Wed, Sep 05, 2007 at 01:04:23AM -0500, Rob Landley wrote:
> On Wednesday 05 September 2007 12:30:42 am Dave Dodge wrote:
> > All of the defined uses of > and < on pointers
[...]
> On Linux, on all platforms I'm aware of, it devolves into (long)a >
> (long)b.
Same here, and I'd add that long is large enough to hold a converted
pointer, and that the address space is linear counting by 1, and that
the conversion is a trivial bit-for-bit operation, and that a null
pointer is all-bits-zero -- none of which is guaranteed by C, but as
far as I know Linux doesn't run on the machines that do otherwise.
> In any case, if there are cases where comparisons are allowed, and treating
> the pointer value as a long works for all those cases, then worrying about
> exactly what the undefined behavior would do if you pull out the same
> comparison code in a case that _isn't_ allowed doesn't seem useful.
It sort of depends on whether you're trying to make a strict C
compiler, or one that allows all of the fudging that gcc does and
handles it in the same way. I agree the latter is a lot more more
useful when the goal is to be able to replace gcc for things like libc
and kernel compilation.
Aside: most commercial compilers also try to be gcc-compatible, though
an interesting one is Intel's C compiler for IA64, which intentionally
does not support inline assembly.
> You worry way more about what the standards document says than I do. :)
That comes from years of skimming comp.lang.c, where the Standard
is law and implementations don't really matter :-)
-Dave Dodge