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

[Rob Landley]

On Wednesday 05 September 2007 1:30:56 am Dave Dodge wrote:
> 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.

Yup.  To be honest, I only _really_ care about this working well on Linux, but 
I care about it working well on all variants of Linux.

Standards bodies tend to have a certain amount of insanity in them due to some 
of the participants (who fund the effort) fighting for an exception for their 
platform.  The posix certification of Windows NT comes to mind...

> > 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'm want something people can actually use, which is definitely on the fudging 
side of things.

One of my vague ideas here is that "make" has outlived its usefulness, and 
that if you do test builds with something like tcc even developers don't 
really need partial rebuilds anymore.

I ranted about it here: http://lkml.org/lkml/2007/9/4/3

> 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.

Yup.  If anybody was going to modify those to work with tcc, they'd have done 
so by now.  We have to modify tcc to build them.

> 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.

People still use IA64?

> > 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 :-)

Rules lawyers.  Wheee...

>                                                   -Dave Dodge

Rob
-- 
"One of my most productive days was throwing away 1000 lines of code."
  - Ken Thompson.