cvs commit: src/lib/libc/sys tls.2
cpressey at catseye.mine.nu
Mon Mar 21 13:18:14 PST 2005
On Mon, 21 Mar 2005 21:47:53 +0100
Joerg Sonnenberger <joerg at 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 at 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.
More information about the Commits