Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!usc!sdd.hp.com!wuarchive!zazen!uwvax!heurikon!ex.heurikon.com!daves
From: daves@ex.heurikon.com (Dave Scidmore)
Newsgroups: comp.lang.c++
Subject: Re: 64 bit architectures and C/C++
Message-ID: <522@heurikon.heurikon.com>
Date: 8 May 91 04:47:20 GMT
References: <168@shasta.Stanford.EDU> <12563@dog.ee.lbl.gov> <312@nazgul.UUCP>
Sender: news@heurikon.heurikon.com
Reply-To: daves@ex.heurikon.com (Dave Scidmore)
Organization: Heurikon Corporation, Madison, WI
Lines: 42

In article <312@nazgul.UUCP> bright@nazgul.UUCP (Walter Bright) writes:
>The most aggravating problem we have is it seems we (Zortech) are the only
>compiler for which:
>	char
>	signed char
>	unsigned char
>are all distinct types! For example,
>	char *p;
>	signed char *ps;
>	unsigned char *pu;
>	p = pu;			/* syntax error */
>	p = ps;			/* syntax error */
>It seems we are the only compiler that flags these as errors.
>A related example is:
>	int i;
>	short *ps;
>	*ps = &i;		/* syntax error, for 16 bit compilers too */
>I think a lot of people are in for a surprise when they port to 32 bit
>compilers... :-)

A lot of compiler writers think they are doing you a favor by not reporting
"trivial" errors. I would much rather have to say:
	char *p;
	signed char *ps;
	unsigned char *pu;
	p = (char*) pu;
	p = (char*) ps;
than to have some subtle error result when I unknowingly perform such an
assigment and some subtle side effect occurs. For example, if the above
"unsigned char" pointer were to be used to read a buffer of characters,
where the end of the buffer was indicated by the value 0x80, if written
initialy on a nine bit per byte machine you would have no problem, but
when ported to an eight bit per byte machine you will never find a
"signed char" equal to 0x80 and so a bug will rear its ugly head. If the
compiler warns that "p = pu" are incompatible types I can look at the
statment and possibly remember that this won't work on an eight bit per
byte machine. If it is what I intended all along, I *should* have used
a cast so the next guy who looks at the code knows that the conversion
is intentional.
--
Dave Scidmore, Heurikon Corp.
dave.scidmore@heurikon.com