Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!seismo!columbia!rutgers!sri-unix!sri-spam!mordor!lll-lcc!ptsfa!ihnp4!plus5!hokey
From: hokey@plus5.UUCP (Hokey)
Newsgroups: comp.lang.c
Subject: Re: Why should "sizeof" be unsigned?
Message-ID: <1750@plus5.UUCP>
Date: Thu, 25-Jun-87 00:18:39 EDT
Article-I.D.: plus5.1750
Posted: Thu Jun 25 00:18:39 1987
Date-Received: Sat, 27-Jun-87 01:12:28 EDT
References: <1748@plus5.UUCP> <586@haddock.UUCP>
Reply-To: hokey@plus5.UUCP (Hokey)
Distribution: world
Organization: Plus Five Computer Services, St. Louis, MO
Lines: 19

sizeof is an operator, not a function.

It doesn't "return" something in the classic sense.

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.

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.

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.

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