This is the mail archive of the gcc-help@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Irritating warnings about implicit functions


On 27 August 2013 21:06, Andy Falanga (afalanga) wrote:
>>
>> > 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 :-)
>
> Code that is compiled after the preprocessor pass.  Sorry, didn't know what else to call it.

That would usually be called preprocessed source, but what makes you
think those functions are declared in the preprocessed source?  All
signs indicate they aren't, or you wouldn't get the warning.

> As for code that reproduces, I can't post the code which I'm actually working on (company policy), but in a nutshell it was nothing more than:
>
> #include <stdio.h>
> #include <stdlib.h>
>
> // compile with: gcc -std=c99 -o prog program.c
> int main() {
>    int fd = popen("ls -l /var/run", "r");
>    if(-1 == fd) exit(2);
>
>    // read from the pipe and do something important
>    pclose(fd);
>
>    return 0;
> }
>
> The only reason this problem surfaced was due to the fact that I needed the compiler to be happy with C99 conventions.  Thus, I had to use -std=c99.  I found the manual pages on feature testing and read about the _GNU_SOURCE macro.  I thought that if I defined it in a *.h file which all files include, which there is one in this very small project, that would be sufficient.  However, that didn't work .. even if I put "#define _GNU_SOURCE" before any includes in the header files.

Of course. If any libc header has been included before you define
_GNU_SOURCE then it's too late, the C library will have decided which
standards to conform to when the first header is included, and setting
_GNU_SOURCE later has no effect.

> I read all about the fact that popen() is a POSIX thing and not standard C.  After many other steps, I decided to see if popen() was actually present after preprocessing: gcc -E ..... .  It was, but yet the compiler said this was an implicitly defined function.

Did you use -std=c99 when preprocessing?  Otherwise you're not
actually producing the same output.

> This was all very strange and I really wished I had more time to actually discover what was really wrong (what I missed).  I have placed
>
> #define _GNU_SOURCE
>
> in all of my source files, as recommended by the feature_test_macros(7) man page, and with the "-std=c99" option, this seems to make the compiler happy.  For this particular week, I'm happy too.

As I said earlier, you could use -std=gnu99 instead of adding it to
every file.  You could also define _GNU_SOURCE on the command line
with -D_GNU_SOURCE.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]