#1447 str[n]casecmp not declared under __STRICT_ANSI__

WSL
closed
None
Bug
fixed
IINR_-_Include_In_Next_Release
False
2015-09-14
2010-06-27
No

$ 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
$

Discussion

  • 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

    Earnie Boyd - 2010-07-06

    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.

     
  • Earnie Boyd

    Earnie Boyd - 2010-07-06
    • milestone: --> 772667
    • status: open --> closed-invalid
     
  • Ramiro Polla

    Ramiro Polla - 2010-07-06

    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

    Earnie Boyd - 2010-07-06

    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

    Ramiro Polla - 2010-07-08

    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

    Earnie Boyd - 2010-07-12

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

     
  • Earnie Boyd

    Earnie Boyd - 2010-07-12
    • status: closed-invalid --> pending-invalid
     
  • Ramiro Polla

    Ramiro Polla - 2010-08-20

    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

     
  • Ramiro Polla

    Ramiro Polla - 2010-08-20
    • status: pending-invalid --> open-invalid
     
  • Ratio

    Ratio - 2011-02-09

    -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

    Earnie Boyd - 2012-10-23

    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

    Earnie Boyd - 2012-10-23
    • milestone: 772667 --> Aged_issue
    • labels: 104601 --> WSL (Windows System Libraries)
    • status: open-invalid --> pending
     
  • Earnie Boyd

    Earnie Boyd - 2013-01-18
    • category: --> Aged_issue
    • milestone: Aged_issue --> WSL
     
  • Earnie Boyd

    Earnie Boyd - 2013-02-08
    • labels: WSL (Windows System Libraries) -->
    • assigned_to: Earnie Boyd
    • type: --> Bug
    • resolution: --> later
    • category: Aged_issue --> No_Documentation
    • patch_attached: --> False
     
  • Earnie Boyd

    Earnie Boyd - 2013-02-19
    • assigned_to: Earnie Boyd --> Keith Marshall
     
  • Earnie Boyd

    Earnie Boyd - 2013-02-19

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

     
  • Thomas Uhle

    Thomas Uhle - 2015-09-10

    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

    Keith Marshall - 2015-09-14
    • status: pending --> closed
    • Resolution: later --> fixed
    • Category: No_Documentation --> IINR_-_Include_In_Next_Release
     
  • Keith Marshall

    Keith Marshall - 2015-09-14

    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.

     

    Related

    Commit: [93fc8c]

Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:





No, thanks