Re: cvs commit: src/lib/libc/sys tls.2

[Chris Pressey <cpressey@xxxxxxxxxxxxxxx>]

On Mon, 21 Mar 2005 21:47:53 +0100
Joerg Sonnenberger <joerg@xxxxxxxxxxxxxxxxx> wrote:

> On Mon, Mar 21, 2005 at 12:31:29PM -0800, Chris Pressey wrote:
> > On Mon, 21 Mar 2005 21:14:14 +0100
> > Joerg Sonnenberger <joerg@xxxxxxxxxxxxxxxxx> wrote:
> > 
> > > On Mon, Mar 21, 2005 at 11:52:49AM -0800, Chris Pressey wrote:
> > > > I wouldn't say it should return an int, though: IMO sizeof(x) ought
> > > > to be treated just like any other numeric constant in C - that is,
> > > > interpreted as signed or unsigned as the situation dictates.  Why
> > > > they introduced this gratuitous unorthogonality, I have no idea. 
> > > > Well, maybe that's not strictly true... I _can_ guess.  Probably
> > > > "sizeof always yields a positive number so we should force its type
> > > > to be unsigned."  But that makes exactly as much sense as "4 always
> > > > yields a positive number so we should force its type to be
> > > > unsigned," which is stupid.
> > > 
> > > Because sizeof(char[2 << 31]) and sizeof(char[2 << 30]) should have
> > > the same type.
> > > 
> > > Joerg
> > 
> > That's what coercion is for.  4294967296 and 2147483648 have the same
> > type when used in the same expression, so why can't sizeof()s which
> > evaluate to those constants do the same?
> 
> Typo, s/2/1/.

OK, then s/4294967296/2147483648/ and s/2147483648/1073741824/ :)

> Or think about sizeof(char[INT_MAX]) vs. sizeof(char[UINT_MAX]).

I have... I fail to see how it changes my point.

-Chris