RE: Irritating warnings about implicit functions

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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

Yes indeed.  I should have tried that first.

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

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.

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.

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.

Andy





[Index of Archives]     [Linux C Programming]     [Linux Kernel]     [eCos]     [Fedora Development]     [Fedora Announce]     [Autoconf]     [The DWARVES Debugging Tools]     [Yosemite Campsites]     [Yosemite News]     [Linux GCC]

  Powered by Linux