Path: utzoo!attcan!uunet!charyb!will
From: will@kfw.COM (Will Crowder)
Newsgroups: comp.lang.c
Subject: Re: IsUnsigned() function?
Summary: oops
Message-ID: <1990Jul30.162449.19240@kfw.COM>
Date: 30 Jul 90 16:24:49 GMT
References: <1990Jul27.161339.14712@kfw.COM> <8118@ncar.ucar.edu>
Reply-To: will@kfw.com (Will Crowder)
Followup-To: comp.lang.c
Distribution: na
Organization: KFW Corporation, Newbury Park, CA
Lines: 32

In article <8118@ncar.ucar.edu> steve@groucho.ucar.edu (Steve Emmerson) writes:
>In <1990Jul27.161339.14712@kfw.COM> will@kfw.COM (Will Crowder) writes:
>
>>What's wrong with:
>
>>#define IsUnsigned(type)	((type)0 - 1 > 0)
>
>Unless I'm mistaken, in ANSI C "(char)0" will, on most machines,
>promote to "signed int" due to the value-preserving rule; consequently,
>the above expression will always be false on those machines, regardless
>of the signedness of "char".
>
>Steve Emmerson        steve@unidata.ucar.edu        ...!ncar!unidata!steve

You're absolutely right, which Karl Heuer also pointed out to me via
e-mail.

I hate the fact that signedness is not preserved, so I probably blocked
it out of my memory due to severe emotional trauma.  :) :) :)  (In other
words, I blew it.)

I've tried ((type)(-1) > 0) on Turbo C and Gnu CC v1.36, and it seems to
work on both.  It does not, however, work on Sun cc.  A compile-time
switch on Turbo C lets you choose whether you want signed or unsigned
chars, which is handy.

Side note: can anyone out there give a good explanation as to why
chars were *ever* signed in the first place, and why ANSI decided not
to require either signed or unsigned chars (leaving it implementation
dependent)?

Will