tinycc-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Tinycc-devel] More fun with comparison between pointer and integer.


From: Rob Landley
Subject: Re: [Tinycc-devel] More fun with comparison between pointer and integer...
Date: Wed, 5 Sep 2007 12:46:00 -0500
User-agent: KMail/1.9.6

On Wednesday 05 September 2007 3:25:59 am Dave Dodge wrote:
> On Wed, Sep 05, 2007 at 02:33:58AM -0500, Rob Landley wrote:
> > On Wednesday 05 September 2007 1:02:03 am Dave Dodge wrote:
> > > > I fixed the "ptr || ptr" bit not working (check hg), and I just made
> > > > it stop warning me about "comparison between pointer and int" for &&
> > > > and ||, but now it's saying "initializer element not constant".
> > >
> > > Well looking at 6.6, I'm having a hard time figuring out how to fit
> > > the above into one of the described forms of "constant expression".
> >
> > It's a pointer to a constant string.  It's in a read-only section of
> > memory.  More to the point, the or is testing whether or not it's
> > nonzero, so the actual _value_ of the pointer goes away and all we
> > need to retain is that it wasn't NULL.
>
> I agree with all that; just saying the Standard doesn't explicitly
> permit it.

Doesn't require it.  If it doesn't forbid it, then it permits it.

> Pretty much the only way it seems to allow using a 
> pointer/address to an object _anywhere_ in a constant expression is in
> sizeof context, or when the final expression is an address

A constant string is an address once the (dynamic) linker's done with it.

printf ("%p\n", "blah");

> (and then 
> there are restrictions that are pretty obviously designed to make the
> address suitable for relocation).  Even simply comparing a
> constant-valued pointer to null seems to put you in
> implementation-defined territory.

The c89 standard didn't insist that char be 8 bytes, either.  Any platform on 
which it wasn't was too broken to worry about.

> > *shrug*  GCC handles this just fine, that's why I was doing it.  The
> > alternative is ugly and brittle #ifdefs instead of letting the optimizer
> > eliminate dead code naturally.
>
> Have not tried this, but maybe you could add another layer to trick
> tcc into taking it:
>
>   (ptr != NULL) || (ptr != NULL) || ... || 0

*shrug*  I could give it a try, but the thing is I have existing code that 
works fine with gcc, and I'd like tcc to be able to parse it too.  
(Unfortunately, understanding constant propogation within tcc is something 
I'm not quite managing to wrap my head around yet.  Haven't looked up all the 
bits of it...)

> Or even more hackish, _if_ you know that in this expression your
> strings are going to be given as string literals (not pointers) and
> have more or less characters than there are in the type produced by
> NULL, then:
>
>   ((sizeof ptr) != (sizeof NULL))

No good.  The size of the string varies.  But if it's not a string, it will be 
NULL, so your first test is reasonable.

(If you're curious what I'm doing, it's my toybox project, main.c, line 61.)

>                                                   -Dave Dodge

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




reply via email to

[Prev in Thread] Current Thread [Next in Thread]