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

[Rob Landley]

On Wednesday 05 September 2007 12:30:42 am Dave Dodge wrote:
> On Tue, Sep 04, 2007 at 11:29:46PM -0500, Rob Landley wrote:
> > and there's defined behavior for > and < too.
>
> You sure about that?

The answer to that question is usually "no" regardless of context.

> All of the defined uses of > and < on pointers 
> in 6.5.8 require the two pointers to point to the same actual object
> (or one past the same object in the case of an array). A null pointer
> doesn't satisfy those cases, and "In all other cases, the behavior is
> undefined".

On Linux, on all platforms I'm aware of, it devolves into (long)a > (long)b.

I'm aware that Solaris behaves incredibly stupidly here, but I've never really 
cared about humoring it.

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.

> 6.5.9 has special wording allowing != and == to apply to null
> pointers.  Interestingly, this means:
>
>   NULL == NULL   defined
>   NULL <= NULL   undefined

Just because the standard's stupid doesn't mean we have to be.

> Of course it's possible I'm missing wording elsewhere that makes null
> pointers work.  As you say, the Standard can be difficult to work
> with.  Just trying to support things like while(p) or (p && ...) where
> p is a pointer is tricky because:
>
>   - They test if the expression p "compares equal with 0",
>
>   - A pointer can only be compared with 0 if that 0 is a
>     null pointer constant.
>
>   - A 0 is only a null pointer constant if it's a constant integer
>     expression.
>
>   - I see nothing that _explicitly_ states that the _implicit_ 0 being
>     compared against is a constant integer expression.  Hmmm.

You worry way more about what the standards document says than I do. :)

I respect both C99 and SUSv3, but I treat them about the same way I treat the 
RFC documents.  (Several of which were well intentioned but never 
implemented, several are obsolete, some were jokes in the first place...)

If the standard is clear and sane, fine.  If the standard is unclear or 
insane, I happily ignore it.

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