Subject: RE: Non-compliant strxfrm
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Date: Mon, 1 Sep 2003 17:04:02 +0100
content-class: urn:content-classes:message
X-MimeOLE: Produced By Microsoft Exchange V6.0.4417.0
Message-ID: <F1A9C8D7A58D1B45A9C16FE7E3DA83D764A3@server.HME.hme.ltd.uk>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: Non-compliant strxfrm
Thread-Index: AcNwoSUQtiNDfryASbSmf2enXeub0gAAHadg
From: "Melvin Curran" <Melvin AT HME DOT Ltd DOT uk>
To: <djgpp-workers AT delorie DOT com>
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by delorie.com id h81G4Bb15615
Reply-To: djgpp-workers AT delorie DOT com

>>     strxfrm(NULL,   "hello", 0) = 0
>>     strxfrm(answer, "hello", 9) = 5
>>     strxfrm(answer, "hello", 3) = 5
>> 
>> For comparison, here is what my function gives for answers:
>> 
>>     strxfrm(NULL,   "hello", 0) = 5
>>     strxfrm(answer, "hello", 9) = 5
>>     strxfrm(answer, "hello", 3) = 2
>
>Linux does not agree:
>
>strxfrm ((null), hello, 0) = 5
>strxfrm (buf, hello, 9) = 5
>strxfrm (buf, hello, 3) = 5
>
>"returns the length of the transformed string" means the
>transformation of the source, not the stored results.  I.e., the
>length *before* truncating to fit the buffer.
>
>Remember, "n" is the size of the output buffer, not the size of the
>input string.

Fair enough, but the first answer from the current strxfrm is still
wrong. I'll rewrite my procedure to match the linux output when I
get home tonight and post it tomorrow.