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

[Rob Landley]

On Wednesday 05 September 2007 5:32:06 pm Dave Dodge wrote:
> On Wed, Sep 05, 2007 at 12:46:00PM -0500, Rob Landley wrote:
> > On Wednesday 05 September 2007 3:25:59 am Dave Dodge wrote:
> > > 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.
>
> Yes, but it's only guaranteed to be a constant expression by the
> Standard if the final expression produces an address.  Things like
> this are well-defined and portable

Hang on, so when char *a is constant, (int)a is _not_ constant?

How does that work?

>   static char * foo = "bar";
>   static char * foo = "bar" + 1;
>
> but your case is not, because your final expression produces an
> integer.
>
> > The c89 standard didn't insist that char be 8 bytes, either.
>
> ITYM 8 bits, and neither does the C99 Standard.

Er, yes.  Bits.

LP64 does and it applies to anything calling itself a "Unix":
http://www.unix.org/whitepapers/64bit.html

But I don't _need_ a standard to say that any platform that doesn't have 8-bit 
bytes isn't interesting.  And strict adherence to a broken standard can 
result in a broken compiler.

> > Any platform on which it wasn't was too broken to worry about.
>
> For Linux certainly.  My understanding is that there are current
> architectures in the embedded market that use a 32-bit char, though.

I haven't heard of them, and am not interested in supporting them.  (I know 
that arm hasn't got instructions to manipulate bytes, but char is still 8 
bits on arm linux.  The compiler emits code to mask and shift to make it 
work, which is why you never want to use a char as a loop index on arm.)

> > (If you're curious what I'm doing, it's my toybox project, main.c,
> > line 61.)
>
> I see the problem.  This adds more ugliness, but like most things you
> can fix it with another layer of abstraction:
>
>   USE_ECHO(NEWTOY(echo, OPT_STR("+en"), TOYFLAG_BIN))
>   USE_TOYSH(NEWTOY(exit, OPT_NONE, TOYFLAG_NOFORK))

No.  If TCC doesn't handle what it's currently doing, TCC is broken, and I 
will fix at least _my_ copy of it.  I honestly don't care what the standard 
says about this, and gcc takes this without flinching right now.

> And then make the trivial definitions alongside NEWTOY and OLDTOY:
>
>   #define OPT_STR(x) x
>   #define OPT_NONE NULL
>
> and
>
>   #define OPT_STR(x) 1
>   #define OPT_NONE 0

Won't.

>                                                   -Dave Dodge

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