Re: The external interface for the parser piece

At 03:15 PM 11/28/00 -0600, Jarkko Hietaniemi wrote:
>On Tue, Nov 28, 2000 at 03:34:22PM -0500, Dan Sugalski wrote:
> > At 01:25 PM 11/28/00 -0600, Jarkko Hietaniemi wrote:
> > >On Tue, Nov 28, 2000 at 07:03:49PM +0000, Tom Hughes wrote:
> > > > Applying the maxim that any software design problem can be solved
> > > > with sufficient levels of abstraction I'd suggest that passing some
> > >
> > >A related warning sign is trying to cram different semantic levels or
> > >types into same data.  (C's "string model" being perhaps the most
> > >obvious example, getchar() having to be an int is another, "0 but true"
> > >a third...I want a "1 but false" :-)
> >
> > Which ways is that one being violated? (I can think of a couple
> > personally... :)
>
>Embedding the (fixed-length) length into the data.  As Nicholas points
>out, that is naughty.  Remember:
>
>         sizeof(char) >= sizeof(short) >= sizeof(int) >= sizeof(long)
>         sizeof(char) == 1
>
>(IIRC) are the only guarantees you get.  No structure alignment/padding
>guarantees.  Let's pick a platform that would have difficulties:
>Cray C-series (nowadays called SV-series, I think).  There's *no*
>integer data type four bytes wide (or two bytes, for that matter).
>It's either 1 (char), or 8.

There's always:

   length = (((((getc() * 256) + getc()) * 256) + getc()) * 256) + getc()

give or take a few parens...

					Dan

--------------------------------------"it's like this"-------------------
Dan Sugalski                          even samurai
[email protected]                         have teddy bears and even
                                      teddy bears get drunk