Steve Hay <[EMAIL PROTECTED]> writes:
>Given that the following C program outputs -1 on my Win32 system:
>
>#include <stdio.h>
>#include <string.h>
>void main(void) {
>    printf("%d\n", stricmp("a", "z"));
>}
>
>why is it that the following XS code outputs -25:
>
>#include <string.h>
>#include "EXTERN.h"
>#include "perl.h"
>#include "XSUB.h"
>void foo(void) {
>    PerlIO_printf(PerlIO_stdout(), "%d\n", stricmp("a", "z"));
>}
>MODULE = Foo    PACKAGE = Foo
>void
>foo()
>
>?  (The value output is not always -25: it varies according to how far 
>apart the two strings being compared are, e.g. stricmp("a", "e") 
>produces -4.)

Which is still withing spec.
AFAIK stricmp like strcmp returns <0, 0 or >0 
with no certainty of the value.


>
>The XS code is linked against msvcrt.dll, and so is the C program when I 
>compile & link it with "/MD" flag.  Both versions are loading up the 
>same version of msvcrt.dll too -- simply the one in C:\WINDOWS\system32.

But strcmp and stricmp are well known functions, so C compile
may well inline them. And when you build XS code you build with options
used to build perl which usually includes optimization.

So stricmp() from DLL may never be called.


>
>msvcrt.dll certainly exports a stricmp(), and there doesn't appear to be 
>one exported from perl58.dll.  I also couldn't see any function 
>replacement games going on in the perl sources for this function.
>
>So how is it that they produce different output?
>
>- Steve
>
>
>------------------------------------------------
>Radan Computational Ltd.
>
>The information contained in this message and any files transmitted with it 
>are confidential and intended for the addressee(s) only.  If you have received 
>this message in error or there are any problems, please notify the sender 
>immediately.  The unauthorized use, disclosure, copying or alteration of this 
>message is strictly forbidden.  Note that any views or opinions presented in 
>this email are solely those of the author and do not necessarily represent 
>those of Radan Computational Ltd.  The recipient(s) of this message should 
>check it and any attached files for viruses: Radan Computational will accept 
>no liability for any damage caused by any virus transmitted by this email.

Reply via email to