Mail Archives: djgpp-workers/2003/09/01/12:04:19
Subject: | RE: Non-compliant strxfrm
|
MIME-Version: | 1.0
|
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>
|
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.
- Raw text -