str{n}casecmp(): unrecognized identifier

[Andrew Talbot]

Hi,

It seems that, on my [x86_64] system, at least, string.h is not being
included in the files where strcasecmp() or strncasecmp() is used (for
example, in crypt32/oid.c), despite HAVE_STRCASECMP and HAVE_STRNCASECMP
being defined as 1.

I presume, because of the above defines, that just adding

#include <string.h>

... in the affected files would not be a proper fix. I imagine it requires
expert tweaking of the automake setup (or whatever) to ensure that this is
done automatically (if it's not just a fault on my system), in which case I
ask for suitable help, please.

Thanks,

-- Andy.

[Marcus Meissner]

On Sat, Sep 30, 2006 at 10:50:27AM +0100, Andrew Talbot wrote:
> Hi,
>
> It seems that, on my [x86_64] system, at least, string.h is not being
> included in the files where strcasecmp() or strncasecmp() is used (for
> example, in crypt32/oid.c), despite HAVE_STRCASECMP and HAVE_STRNCASECMP
> being defined as 1.
>
> I presume, because of the above defines, that just adding
>
> #include <string.h>
>
> ... in the affected files would not be a proper fix. I imagine it requires
> expert tweaking of the automake setup (or whatever) to ensure that this is
> done automatically (if it's not just a fault on my system), in which case I
> ask for suitable help, please.

Actually we have to use wine/port.h.

I sent in a patch (47545629d62da964293348a905f886162aae4f85).

Ciao, Marcus

[Dmitry Timoshkov]

"Andrew Talbot"  wrote:
> It seems that, on my [x86_64] system, at least, string.h is not being
> included in the files where strcasecmp() or strncasecmp() is used (for
> example, in crypt32/oid.c), despite HAVE_STRCASECMP and HAVE_STRNCASECMP
> being defined as 1.

str[n]casecmp should be used only to compare strings received from an
underlying system, in all other cases win32 API lstrcmp[i]A should be
used instead, otherwise bad side effects could arise due to using wrong
locale.

[Andrew Talbot]

Dmitry Timoshkov wrote:
> str[n]casecmp should be used only to compare strings received from an
> underlying system, in all other cases win32 API lstrcmp[i]A should be
> used instead, otherwise bad side effects could arise due to using wrong
> locale.

I see. I would mention that, currently, there are about forty-two places in
the dll files where one or other of these functions is used. (I don't know
about the programs, tools or dll/tests directories.)

Thanks,

-- Andy.