Xref: utzoo comp.sys.ibm.pc:11777 comp.lang.c:7230
Path: utzoo!utgpu!water!watmath!clyde!rutgers!sri-spam!ames!amdcad!sun!plx!slvblc!dick
From: dick@slvblc.UUCP (Dick Flanagan)
Newsgroups: comp.sys.ibm.pc,comp.lang.c
Subject: Re: Bug in ANSI C??
Message-ID: <488@slvblc.UUCP>
Date: 14 Feb 88 07:49:42 GMT
References: <5331@cit-vax.Caltech.Edu> <241@oracle.UUCP> <2118@bsu-cs.UUCP>
Sender: uupc@slvblc.UUCP
Reply-To: dick@slvblc.UUCP (Dick Flanagan)
Followup-To: comp.lang.c
Organization: SLV Systems Group, Ben Lomond, CA
Lines: 31
Disclaimer: none

In article <2118@bsu-cs.UUCP> dhesi@bsu-cs.UUCP (Rahul Dhesi) writes:
>In article <241@oracle.UUCP> rbradbur@oracle.UUCP (Robert Bradbury) writes:
>>On another note; does everyone realize that the current standard allows
>>the results of the str/memcmp() function to be implementation defined
>>if the characters being compared have the high-bit set?
>
>You mean that I can have two identical strings with high bits set, and
>strcmp() could return something other than 0?

No.  Equal is equal.

>Or does the problem lie only in deciding lexical order?

The problem lies in that the developer of the run-time routines is free
to decide that strcmp() is comparing *signed* eight-bit numbers, so that
any character with the high-bit set is considered to be *lower* than any
character with the high-bit off.  This would mean that the non-equal
returns could differ between one compiler and another.

>While we're on the subject, just what is the meaning of "implementation-
>defined"?

"Left to the discretion of the compiler run-time routine developer."

Dick

--
Dick Flanagan, W6OLD                         GEnie: FLANAGAN
UUCP: ...!ucbvax!ucscc!slvblc!dick           Voice: +1 408 336 3481
INTERNET: slvblc!dick@ucscc.UCSC.EDU         LORAN: N037 05.5 W122 05.2
USPO: PO Box 155, Ben Lomond, CA 95005