Path: utzoo!utgpu!water!watmath!clyde!rutgers!umd5!purdue!i.cc.purdue.edu!j.cc.purdue.edu!pur-ee!iuvax!bsu-cs!dhesi
From: dhesi@bsu-cs.UUCP (Rahul Dhesi)
Newsgroups: comp.sys.ibm.pc
Subject: Bug in ANSI C??
Summary: WHAT??
Keywords: memcmp, memmove, strcmp, memcmp
Message-ID: <2118@bsu-cs.UUCP>
Date: 14 Feb 88 22:59:19 GMT
References: <5331@cit-vax.Caltech.Edu> <241@oracle.UUCP>
Reply-To: dhesi@bsu-cs.UUCP (Rahul Dhesi)
Followup-To: comp.lang.c
Distribution: comp.sys.ibm.pc,comp.lang.c
Organization: CS Dept, Ball St U, Muncie, Indiana
Lines: 20

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?  This would be truly a
serious flaw in the standard.

Or does the problem lie only in deciding lexical order?  That's not so
bad--I wouldn't trust the standard library in that case anyway, since
we all have our own opinions about what lexical order is correct.

While we're on the subject, just what is the meaning of "implementation-
defined"?  E.g., "Oh, by the way, I would avoid comparing strings
with high bits set, since the result is implementation-defined.  On
this particular system the result is that all disk packs are erased and
the system halts."
-- 
Rahul Dhesi         UUCP:  <backbones>!{iuvax,pur-ee,uunet}!bsu-cs!dhesi