Path: utzoo!mnetor!uunet!seismo!sundc!pitstop!sun!amdcad!ames!umd5!mimsy!chris
From: chris@mimsy.UUCP (Chris Torek)
Newsgroups: comp.lang.c
Subject: Re: unsigned & char's
Message-ID: <10104@mimsy.UUCP>
Date: 8 Jan 88 17:15:03 GMT
References: <1167@ark.cs.vu.nl>
Organization: U of Maryland, Dept. of Computer Science, Coll. Pk., MD 20742
Lines: 31
Keywords: interpretation of type rules, signed char's, unsigned's

In article <1167@ark.cs.vu.nl> jcvw@cs.vu.nl (Winkel van Jan Christiaan) writes:
>... characters like 0xf1 (ebcdic for '1') are negative when using
>signed char's (the default in most c's). ... Therefore I use a
>typecast to an unsigned. The compiler will however still generate
>the same code. The code does not change until I define p to be an
>unsigned char *. I thought that the typecast made my wish clear to
>the compiler that I do not want sign extension, but just an
>unsigned extension ...

A type cast is semantically equivalent to an assignment to an unnamed
variable with the type of the cast.  Hence

	char *p; ...
	*p = ebc2asc[*p];

and

	*p = ebc2asc[(unsigned)*p];

both ask to evaluate *p, then convert to type `int' (`char' extends
to `int').  The second asks futher that this value be converted to
type `unsigned int'.  The problem is getting *p to extend without
sign extension.  There are alternatives:

	*p & 0xff;		/* extend to int, then throw out the sign */
	(unsigned char) *p;	/* extend to int, truncate to u_char,
				   extend without sign extension to u_int */
	*(unsigned char *)p;	/* extend without sign extension to u_int */
-- 
In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7690)
Domain:	chris@mimsy.umd.edu	Path:	uunet!mimsy!chris