Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!seismo!rutgers!sri-spam!mordor!lll-tis!ptsfa!ihnp4!homxb!mhuxt!mhuxm!mhuxo!ulysses!sfmag!sfsup!mpl
From: mpl@sfsup.UUCP (M.P.Lindner)
Newsgroups: comp.lang.c
Subject: Re: Why should "sizeof" be unsigned?
Message-ID: <1557@sfsup.UUCP>
Date: Fri, 26-Jun-87 12:48:48 EDT
Article-I.D.: sfsup.1557
Posted: Fri Jun 26 12:48:48 1987
Date-Received: Sat, 27-Jun-87 14:04:38 EDT
References: <1748@plus5.UUCP> <586@haddock.UUCP> <1750@plus5.UUCP>
Organization: AT&T-IS, Summit N.J. USA
Lines: 28
Summary: you're missing the point

In article <1750@plus5.UUCP>, hokey@plus5.UUCP writes:
> sizeof is an operator, not a function.
	correct, go on... 
> It doesn't "return" something in the classic sense.
	au contrare, operators return values, otherwise 1+1 wouldn't be 2.
	However, if you mean they don't have an explicit "return" statement,
	granted (although this is not relevant).
> I see no reason to have this operator have a "side effect" of an explicit
> cast of its "value", especially when this cast is hidden and arguably
> unnecessary.
	No "side effect" is necessary.  Just as a == b returns an int regardless
	of the type of its operands, sizeof returns an unsigned.  No cast is
	involved, just as you don't have to say (int) (a == b).
> One can write subroutines like malloc without a size_t.  Use function
> prototypes.  This has the added benefit of permitting the compiler to
> warn you if you will loose precision as part of the cast.
	Right on! 
> If one wishes, one could say our desire to treat a "length" counter of -1
> is out of band data.  Using that logic, a nil pointer is out of band data, too.
	The fact is, a "length" of -1 is not just out of band data, it's data
	that can't be held by the type of the sizeof operator.  "nil" is out of
	band, but can still be represented in a pointer.  For an analogy, "not
	a number" is out of band for a float, but is still representable.
> Perhaps we should get rid of the nil pointer, and use a structure of a flag
> value and a pointer, and only use the pointer if the flag value is true.
> -- 
> Hokey
	I'm not sure I follow this, but I will assume it's sarcasm.