Questions about C on a Prime (primix)

[Bud Greasley]

In article <2023 at brl-smoke.ARPA> gwyn at brl-smoke.ARPA (Doug Gwyn ) writes:
>In article <325 at hadron.UUCP> jsdy at hadron.UUCP (Joseph S. D. Yao) writes:
>>In article <988 at plus5.UUCP> hokey at 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 at brl-smoke.ARPA> gwyn at 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