From owner-freebsd-hackers  Wed Jun  4 05:45:46 1997
Return-Path: <owner-hackers>
Received: (from root@localhost)
          by hub.freebsd.org (8.8.5/8.8.5) id FAA25781
          for hackers-outgoing; Wed, 4 Jun 1997 05:45:46 -0700 (PDT)
Received: from squirrel.tgsoft.com (squirrel.tgsoft.com [207.167.64.183])
          by hub.freebsd.org (8.8.5/8.8.5) with SMTP id FAA25774
          for <hackers@FreeBSD.ORG>; Wed, 4 Jun 1997 05:45:42 -0700 (PDT)
Received: (qmail 946 invoked by uid 128); 4 Jun 1997 12:45:24 -0000
Date: 4 Jun 1997 12:45:24 -0000
Message-ID: <19970604124524.945.qmail@squirrel.tgsoft.com>
From: mark thompson <thompson@squirrel.tgsoft.com>
To: un_x@anchorage.net
CC: hackers@FreeBSD.ORG
In-reply-to: message from Steve Howe on Mon, 2 Jun 1997 21:40:41 -0800 (AKDT)
Subject: Re: signed/unsigned cpp
Sender: owner-hackers@FreeBSD.ORG
X-Loop: FreeBSD.org
Precedence: bulk

   From: Steve Howe <un_x@anchorage.net>
   Date: Mon, 2 Jun 1997 21:40:41 -0800 (AKDT)

   On Tue, 3 Jun 1997, David Nugent wrote:

   > 
   > It isn't only a portability issue, but also a c++ standards issue.
   > c++ distinguishes between these three types. Ansi c only has two
   > and there it *is* a portability issue as to whether char* is signed
   > or unsigned. This is one of the many ambiguities that c++ has the
   > luxury to resolve. :)

   i hate to carry on anything trivial ... but,

Agreed.

   having a "default signedness" seems like trouble to me.  when you
   are writing code, you should have some intentions for a signedness.
   imho, c++ should've just kept 2 types of signedness and made sure
   one or the other was always specified - then you wouldn't have
   the kludge of "whatever some other compiler deems it to be".
   i can't imagine a worthwhile use of that.

It is a carryover from C. The rule in C was that each base type was
defined to be whatever was "natural" on the underlying machine. Some
machines only have native instructions for one type of char or
another. (The unsupported flavor would require two or more
instructions). Hence, C did not specify which type you would get by
default. 

Neither does C++. But ANSI at least added the rigor of allowing you to
specify which one you needed, and considering the misuse of the types as
a portability issue.

   if i am using an "unsigned char *", i expect my code to use an
   "unsigned char *".  it does not benefit any cross-compiler
   or any other architecture to say "no - i will use it as
   a signed char *".

Actually, 'char' is a fine, useful and portable type, if you use it for
7-bit characters, or integers 0..127. Or if you only store characters
and compare them for equality.

   but i have been wrong before :)

Hmmm...

-mark