Irritating warnings about implicit functions

Jonathan Wakely
Tue Aug 27 13:49:00 GMT 2013

On 26 August 2013 17:58, Andy Falanga (afalanga) wrote:
>> You forgot to include example code that demonstrates the problem.
> Trying to make a small, reproducible case forced me to take a different path which led to the solution.

That's one of the main benefits of making a small reproducible case.
Without it, it's difficult for anyone to help you, and with it, 9
times out of 10 you don't need the help because reducing it identifies
the problem.

>  The solution I was trying was to place the define for _GNU_SOURCE in a "master" header file which is used by all others.  I was apparently missing an include which happened earlier on and prevented definition at the point I'd placed it from taking hold.  The solution appears to be what I found in the feature_test_macros(7) man page: placing the #define _GNU_SOURCE in the *.c file *before any* includes.  This prevents the irritating warnings even when compiling with -std=c99 (as it should).
> Just out of curiosity, could you explain why, even with the functions popen(), pclose() and syscall() being in the code sent to the compiler, the compiler would complain that they were implicitly defined?

I don't know what you mean by "being in the code sent to the compiler"
and you haven't provided example code that reproduces the problem :-)

Those functions are defined by POSIX and are not part of the C
standard, so if you tell GCC to compile in strict C99 mode (e.g. with
-std=c99) then in general you don't get non-standard declarations.  If
you define the relevant POSIX feature test macros shown in the popen
man page then you get the POSIX API.  If you define _GNU_SOURCE (or
compile with -std=gnu99) then you get them, because _GNU_SOURCE
includes everything defined by POSIX and additional GNU extensions.

More information about the Gcc-help mailing list