Path: utzoo!utgpu!jarvis.csri.toronto.edu!clyde.concordia.ca!mcgill-vision!bloom-beacon!bu.edu!bu-cs!snorkelwacker!apple!archer!dwb
From: dwb@archer.apple.com (David W. Berry)
Newsgroups: comp.sys.mac.programmer
Subject: Re: String Copy in THINK C 4.0
Message-ID: <6548@internal.Apple.COM>
Date: 7 Feb 90 00:53:53 GMT
References: <2083@quiche.cs.mcgill.ca> <2826@draken.nada.kth.se> <34105@ucbvax.BERKELEY.EDU> <2834@draken.nada.kth.se>
Sender: usenet@Apple.COM
Organization: Apple Computer
Lines: 16

In article <2834@draken.nada.kth.se> d88-jwa@nada.kth.se (Jon W{tte) writes:
>In article <34105@ucbvax.BERKELEY.EDU> oster@dewey.soe.berkeley.edu.UUCP (David Phillip Oster) writes:
>>In article <2826@draken.nada.kth.se> d88-jwa@nada.kth.se (Jon W{tte) writes:
>>>memmove(p2, p1, *p1 + 1); /* copies pascal string p1 to p2 */
>>		^ This is NOT the right way to get the length of a pascal
>
>This is, of course, the right and _efficient_ way to do _this_ operation.
>It doesn'n fail, given two legal pascal strings. I suppose I could even
>prove it, strongly.
>
>Of course, the rest of the article is right about _that_ special case,
>but that doesn't happen in this case.
	Actually, it's not such a special case.  A legal pascal string
may have up to 255 characters.  Any more than 127 is going to cause a
sign extension problem.  Remember, there defined using char, not unsigned
char.  All of a sudden it's a much rarer problem...