Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!seismo!plus5!hokey
From: hokey@plus5.UUCP (Hokey)
Newsgroups: comp.lang.c
Subject: Why should "sizeof" be unsigned?
Message-ID: <1748@plus5.UUCP>
Date: Thu, 18-Jun-87 13:09:25 EDT
Article-I.D.: plus5.1748
Posted: Thu Jun 18 13:09:25 1987
Date-Received: Sun, 21-Jun-87 13:17:19 EDT
Reply-To: hokey@plus5.UUCP (Hokey)
Distribution: world
Organization: Plus Five Computer Services, St. Louis, MO
Lines: 39

Is there a good or overriding reason why the sizeof operator must return
an explicitly unsigned value?

We have an application which stores strings in a "local" array if the strings
are small enough, otherwise it malloc()s space and saves the string in the
malloc()ed space.  In any event, we keep track of the string length.

There are 3 interesting cases: no string, a zero-length string, and >0 length
strings.  We thought it would be a swell idea to denote the "no string" case
with a length counter of -1.  Normally, this is a neat idea.  However, there
are cases in which we only want to mess around with strings which are bigger
than the local array size.  For these cases, we  can not use the expression

	length > sizeof local_string_buffer

because the -1 length (no string available) becomes slightly larger than the
number of bytes in the local string buffer when converted to unsigned.

For what it is worth:

	This is happening in a speed-critical section of code.
	We are very thorough and very lazy.
	We *could* add 1 to all our lengths and solve this problem (and
	create some others).
	I can think of several other ways to "get around" the problem
	(presently, we cast most sizeof operators to int).

None of these issues are key - it seems to me having sizeof return an
explicitly unsigned value violates "the principle of least astonishment".

One of the primary uses of sizeof is to make code more readable, portable, and
maintainable.  If I am on a machine with 4 byte character pointers and I want
to write nonportable code by not using sizeof(char *), I am more likely to use
"4" than "4U" (which will only work on "new" compilers anyway).

Then again, I think the size_t is pretty useless and that the proposed C
standard contains far too many typedefs that work against the good programmer.
-- 
Hokey