#1447 str[n]casecmp not declared under __STRICT_ANSI__

[Ramiro Polla]

$ cat strings.c
#include <strings.h>

void foo(void)
{
strcasecmp(NULL, NULL);
strncasecmp(NULL, NULL, 0);
}
$ i686-mingw32-gcc -o strings.o -c strings.c -std=c99 -Werror=implicit-function-declaration
strings.c: In function 'foo':
strings.c:5: error: implicit declaration of function 'strcasecmp'
strings.c:6: error: implicit declaration of function 'strncasecmp'
$ cat strcasecmp.diff
--- /usr/i686-mingw32/include/string.h.orig 2010-06-27 13:46:10.000000000 -0300
+++ /usr/i686-mingw32/include/string.h 2010-06-27 14:01:04.000000000 -0300
@@ -116,6 +116,9 @@
#endif /* _UWIN */
#endif /* _NO_OLDNAMES */

+#else
+int __cdecl __MINGW_NOTHROW strcasecmp (const char*, const char *);
+int __cdecl __MINGW_NOTHROW strncasecmp (const char *, const char *, size_t);
#endif /* Not __STRICT_ANSI__ */

#ifndef _WSTRING_DEFINED
$ sudo patch -p0 < strcasecmp.diff
patching file /usr/i686-mingw32/include/string.h
$ i686-mingw32-gcc -o strings.o -c strings.c -std=c99 -Werror=implicit-function-declaration
$

[Christophe PARIS]

Thanks for the fix.
I'm having the same problem here trying to cross-compile ffmpeg.
hope it will be officially fixed soon.

[Earnie Boyd]

strcasecmp and strncasecmp are not ANSI required. Therefore of course __STRICT_ANSI__ is going to exclude them. The fix therefore is to not use __STRICT_ANSI__ if you want to use these functions.

[Ramiro Polla]

Sorry, I got the wrong standard...
'man strcasecmp' says 4.4BSD, POSIX.1-2001.
It should be available under some other ifdef then.
(Is it possible to change the bug title? I couldn't figure out how. should I open a feature request?)

[Earnie Boyd]

Windows doesn't supply POSIX functionality and therefore __STRICT_ANSI__ is still incorrect if you want these functions; so, no, there is no feature request that would be accepted.

[Ramiro Polla]

Hi Earnie,
As you might have noticed on my last reply, I have already acknowledged that checking for ansi is the wrong way to go. This function is actually part of c99, just like gettimeofday(), which you already support (even under -ansi, which is probably a bug). The check should probably go under "__STDC_VERSION__ >= 199901L" (which you also already have in a few places).

[Earnie Boyd]

You will need to point me to the documentation that says this is part of C99.

[Ramiro Polla]

Sorry, I have not found documentation linking it to C99. This assumption was based on comments from other people.
I have found it defined in POSIX[1]. It is defined under _BSD_SOURCE on glibc and _POSIX_C_SOURCE on macosx.
I know Windows doesn't supply POSIX functionality but this function is already being provided by mingw, it would be nice to have its definition as well.
[1] http://www.opengroup.org/onlinepubs/9699919799/functions/strcasecmp.html

[Ratio]

-std=c99 define __STRICT_ANSI__ macro and disable strcasecmp build-in gcc function
__STRICT_ANSI__ macro can/must remove strcasecmp from string.h
but not need remove strcasecmp from strings.h, because header is not part of c standard library
strings.h header is part of POSIX and external for compiler in c99 mode

because in c99 mode compiler don't know about strcasecmp, we can safely use it outside standard c99 headers

"strcasecmp is defined in strings.h, which is not part of C99. So -std=c99 vs. -std=gnu99 shouldn't have any affect."
http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/2010-July/092878.html

[Earnie Boyd]

Decide what to do with this.

Strings.h is provided for compilability and simply includes string.h.

I need a good C99 reference.

[Earnie Boyd]

Keith, I've assigned to you for you input to this ticket.

[Thomas Uhle]

It is still annoying that strcasecmp() is not available after including strings.h. Due to POSIX.1-2008 the header file strings.h is definitely the correct place for the definitions of strcasecmp() and strncasecmp(). Hence, these definitions should be moved from string.h to strings.h and perhaps could be guarded by

#if _POSIX_C_SOURCE

or something alike.

[Keith Marshall]

Uh, oh. I completely overlooked that Earnie had assigned this to me, for review. Belatedly, here's my take on it:--

1. <strings.h> may have been the forerunner of <string.h>, in early BSD Unix distributions, but this usage is long obsolete. Today, <string.h> is an ISO-C standard header, while <strings.h> is a POSIX.1 header with an entirely distinct purpose. It is utterly wrong that MinGW's <strings.h> should simply include <string.h>, and consider its job to be done; indeed, it is wrong that <strings.h> should include <string.h> at all.
2. As an ISO-C standard header, it is entirely appropriate that any extensions to ISO-C which <string.h> declares should be occluded, when __STRICT_ANSI__ is in effect, unless some other feature test macro is specified to re-enable them.
3. The declarations of strcasecmp() and strncasecmp(), which are POSIX functions not specified for ISO-C, belong in the POSIX.1 <strings.h> header. Since this is not an ISO-C header, there is no reason for __STRICT_ANSI__ to have any effect on the declarations which it provides. I'm not even convinced that there should be any need to specify _POSIX_C_SOURCE to make these declarations visible; simply including <strings.h> should suffice.

With the above in mind, I've committed [93fc8c], which I believe fixes this issue.