Re: [Tinycc-devel] Fun little bug...

[Dave Dodge]

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