Path: utzoo!attcan!uunet!tank!uwvax!rutgers!mit-eddie!bloom-beacon!bu-cs!dartvax!eleazar.dartmouth.edu!earleh
From: earleh@eleazar.dartmouth.edu (Earle R. Horton)
Newsgroups: comp.sys.mac.programmer
Subject: Re: LSC string copy bug
Message-ID: <10942@dartvax.Dartmouth.EDU>
Date: 16 Nov 88 18:52:35 GMT
References: <930@paris.ics.uci.edu>
Sender: news@dartvax.Dartmouth.EDU
Reply-To: earleh@eleazar.dartmouth.edu (Earle R. Horton)
Distribution: all
Organization: Thayer School of Engineering
Lines: 33
Summary:
Expires:
Sender:
Followup-To:
Keywords:

In article <930@paris.ics.uci.edu> mac@ics.uci.edu (MAC ICS199 ACCOUNT) writes:
 >
I>I'm comparing two string using the standard STRCMP function in
 >LSC 3.0.
H>
A>It looks something like this:
T>
E>strcmp(s1, s2)
 >char *s1, *s2;
I>	for (; *s1 == *s2 ; s1++, s2++) if (!*s1) break;
N>	return (*s1 - *s2);
E>}
W>
S>Seem to work fine except when I pass it a string consisting of
!>leading 0xFF (or '\377') characters in s1. It always return
!>something less than 0 (the debugger says *s1 == -1). Anyone
!>know why this doesn't work.
 >
This happens because the char data type is signed in most Macintosh C
compilers.  I don't know about LSC 3.0, but this is true for LSC 2.15,
MPW C 2.0.2, and Aztec v 3.6c.  Under these conditions, 0xFF is,
indeed, equal to -1.  If you need a correct return value from strcmp,
recompile the library function to use "unsigned char *s1,*s2;."

If you do this, then your code becomes somewhat less than portable,
since other LSC programmers will have no idea that you are using an
unsigned strcmp().  If you desire portability in addition to correct
results, then rename the modified routine, and include its code in
your programs.

Earle R. Horton. 23 Fletcher Circle, Hanover, NH 03755
(603) 643-4109
Sorry, no fancy stuff, since this program limits my .signature to three