Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.1 6/24/83; site hcrvx1.UUCP
Path: utzoo!hcrvax!hcrvx1!bud
From: bud@hcrvx1.UUCP (Bud Greasley)
Newsgroups: net.lang.c
Subject: Re: Questions about C on a Prime (primix)
Message-ID: <1324@hcrvx1.UUCP>
Date: Thu, 27-Mar-86 12:52:37 EST
Article-I.D.: hcrvx1.1324
Posted: Thu Mar 27 12:52:37 1986
Date-Received: Fri, 28-Mar-86 03:09:10 EST
Organization: Human Computing Resources, Toronto
Lines: 47




In article <2023@brl-smoke.ARPA> gwyn@brl-smoke.ARPA (Doug Gwyn ) writes:
>In article <325@hadron.UUCP> jsdy@hadron.UUCP (Joseph S. D. Yao) writes:
>>In article <988@plus5.UUCP> hokey@plus5.UUCP (Hokey) writes:
>>>I was told that their C port keeps the 8th bit *on* for all ascii characters.
>>>This seems kind of strange.  Near as I can tell, this means the following
>>>code fragment won't work:
>>>	strcpy(dst, src)
>>>	    char *dst;
>>>	    char *src; {
>>>		while(*dst++ = *src++) ;
>>>		return;}
>>I've never really liked this kind of code:  it always seemed to me
>>to be assuming something that, someday, on some weird machine, would
>>fail.  Surprise!
>>My rule is to always use an explicit reference to a defined constant:
>>	while ((*dst+= = *src++) != NUL);
>>This way, if my character set changes, I worry about this less.  By
>>the way, will your P**** machine take a constant like
>>	#define NUL	'\0'
>>and turn it into an eighth-high character?

>No, the NUL terminator (both in practice and as you #define it)
>will be a 0-valued byte.  The original code, although ugly, is
>correct.

	This is correct.  The Prime C-compiler understands
	'\0' (octal 0) as the null character.  Comparisons such
	as described above will work correctly, as will comparisons
	of the form:
	  	while(*s++ != 0);

In article <2020@brl-smoke.ARPA> gwyn@brl-smoke.ARPA (Doug Gwyn ) writes:

>Any C implementation that insists on having the high bit set
>for normal character (char)s should also treat (char) as
>(unsigned char), or else there will be sign-propagation
>constants when (char)s are widened to (int).  Otherwise,
>this is a permissible (although unusual) implementation choice.

	This also is the case.  The Prime C-compiler does not
	do sign extension.
-- 
 	Bud Greasley
	{decvax|watmath|utzoo}!hcr!hcrvax!bud