Menu

#20 Missing #include

v1.0_(example)
closed-fixed
nobody
None
5
2017-08-06
2017-03-05
No

Building postrace-1.14 on OS X 10.11...

clang -DHAVE_CONFIG_H -I. -I.. -I/sw/include -g -O2 -MT main.o -MD -MP -MF .deps/main.Tpo -c -o main.o main.c
main.c:767:22: warning: implicitly declaring library function 'strdup' with type 'char (const char )' [-Wimplicit-function-declaration]
info.outfile = strdup(optarg);
^
main.c:767:22: note: include the header <string.h> or explicitly provide a declaration for 'strdup'

and likewise in backend_eps.c and mkbitmap.c.

Interestingly, these .c already do have #include <string.h>. As a blind voodoo attempt, I commented out the #define _XOPEN_SOURCE 500 in each of those .c, and the warnings went away (and no other warnings appeared). So I dove into my system headers and experimented further, and switching them instead to #define _XOPEN_SOURCE 600 also solves it.

The only note I see in the doc files about _XOPEN_SOURCE is where INSTALL recommends using it manually on certain platforms. If it's always hardcoded in the .c now, that note is no longer correct. But if we have that note, do we really need the .c hardcoded? Or if you want to keep it hardcoded, is there harm to harcoding 600 now instead of 500? Not sure how common non-ANSI compilers are, whether it's worth a ./configure test or something.

Discussion

  • Peter Selinger

    Peter Selinger - 2017-03-06

    Thanks for reporting this. The _XOPEN_SOURCE macro is defined by source code to declare a compatibility level for the functions that the source code uses; the standard header files use this to figure out which function prototypes to define. For example, _XOPEN_SOURCE=500 refers to the X/Open 5 standard, incorporating POSIX 1995. _XOPEN_SOURCE=600 refers to the X/Open 6 standard, incorporating POSIX 2004. Both standards include strdup, so _XOPEN_SOURCE=500 should be sufficient to get the strdup prototype. So in principle this is a bug in macOS, not in Potrace. But I will change it to 600 in the next release, because I don't think it will do any harm.

    The Potrace documentation says nothing about _XOPEN_SOURCE, because it is not a configuration flag: the purpose of _XOPEN_SOURCE is not to provide information about the environment to the source code, but to provide information about the source code to the environment.

    The INSTALL file is completely generic; the same generic instructions are used for all software using the autoconf/automake build system. Defining _XOPEN_SOURCE on the command line only makes sense if the source code does not already define it; this can be useful, only in exceptional situations, to increase the compatibility of some exotic compilers. It is not something one would normally want to do. (I'm not sure when was the last time I have seen a HP-UX system. In the 1990s, perhaps?)

     
  • Peter Selinger

    Peter Selinger - 2017-03-06
    • status: open --> closed-fixed
     
  • Peter Selinger

    Peter Selinger - 2017-08-04

    Daniel,

    contrary to what I previously thought, I found that defining _XOPEN_SOURCE = 600 breaks the build on some other systems. I am considering using #define _POSIX_C_SOURCE 200809L instead. Could you please check whether this causes any problems on OS X?

    Thanks, -- Peter

     
  • Daniel Macks

    Daniel Macks - 2017-08-05

    That alternative #define works equally well on my 10.11

     
  • Peter Selinger

    Peter Selinger - 2017-08-06

    OK, thanks!

     

Log in to post a comment.