popen implicitly declared even though #include is added

Question

This is tiny snippet of my code.

   #include <stdio.h>
   #include <unistd.h>
   #include <stdlib.h>
   #include <time.h>
   #include <sys/stat.h>
   #include <sys/wait.h>
   #include <sys/types.h>
   #include <string.h>
   #include <sys/types.h>
   #include <sys/socket.h>
   #include <netinet/in.h>
   #include <arpa/inet.h>
    ...

   FILE * pipe;
    ...

   pipe = popen ("ls /tmp -1", "r");
    ...
   pclose(pipe);

blarg.c:106: warning: implicit declaration of function ‘popen’

blarg.c:106: warning: assignment makes pointer from integer without a cast

blarg.c:112: warning: implicit declaration of function ‘pclose’

blarg.c:118: warning: assignment makes pointer from integer without a cast

I'm really unsure. I looked up popen and all it requires is stdio.h which is provided. What is missing, or is the problem in the rest of my code (I don't really want to show more code because its an a assignment).

Maybe you are compiling with options to GCC such as `-ansi` or `-std=c99`; these prevent the POSIX extensions from being visible. To make them visible, you have to request them, by (for example) specifying `#define _XOPEN_SOURCE 500` (or 600 or 700) before you include any system header. — Jonathan Leffler, Mar 29 '11 at 06:59

score 15 · Answer 1 · answered Dec 31 '16 at 07:14

15

Replace -std=c99 or -std=c11 etc with -std=gnu99 or -std=gnu11.

answered Dec 31 '16 at 07:14

weakish

28,682
5
48
60

I replaced `-std=c17` with `-std=gnu17`. Worked. – Gabriel Staples Feb 03 '22 at 22:35

score 14 · Answer 2 · answered Mar 29 '11 at 05:52

14

As the man page says:

Feature Test Macro Requirements for glibc (see feature_test_macros(7)):

popen(), pclose(): _POSIX_C_SOURCE >= 2 || _XOPEN_SOURCE || _BSD_SOURCE
|| _SVID_SOURCE

So you should #define _BSD_SOURCE or one of the others before #includeing stdio.h.

answered Mar 29 '11 at 05:52

Conrad Meyer

2,851
21
24

let me try it out. This is interesting because I have used pipe in the past (almost with the exact same code) and it worked. Any reason why? – Chris Allen Mar 29 '11 at 05:56
Hmm, it seemed to calm down half of the popen and pclose complaints. Thanks for your help though. – Chris Allen Mar 29 '11 at 06:03
5

You should define `_POSIX_C_SOURCE` or `_XOPEN_SOURCE`. The others are not (current) standards. `_SVID_SOURCE` may have been a standard at one time but the age of SVID is something like 15 years past... – R.. GitHub STOP HELPING ICE Mar 29 '11 at 12:16
1

I'm also still getting the same error. I take it that the answer is outdated. – Tomáš Zato May 12 '14 at 12:03
2

The man page for popen(3) still shows the same requirements. The stdio.h header also clearly shows these requirements: 867 #if (defined __USE_POSIX2 || defined __USE_SVID || defined __USE_BSD || \ 868 defined __USE_MISC) I don't get any errors here with -D_POSIX_C_SOURCE=2. – Conrad Meyer Jul 01 '14 at 18:24

score 0 · Answer 3 · answered Aug 09 '23 at 21:51

I ran into this problem in MinGW; in its stdio.h I found:

#ifndef NO_OLDNAMES
_CRTIMP __cdecl __MINGW_NOTHROW  FILE *  popen (const char *, const char *);
_CRTIMP __cdecl __MINGW_NOTHROW  int     pclose (FILE *);
#endif

And it turns out I had -DNO_OLDNAMES=1 on my gcc command line to fix some obscure problem in another source file that I can't even recall anymore. This was my easy fix:

#ifdef NO_OLDNAMES
  #undef NO_OLDNAMES
#endif
#include <stdio.h>

score -6 · Answer 4 · answered Mar 29 '11 at 17:48

-6

I put the prototypes of popen and pclose at the top of my code. It seemed to have settled the problem.

answered Mar 29 '11 at 17:48

Chris Allen

653
4
9
17

6

Do not do that - it is a bad way to fix the problem. Use the standard headers, and get the defines right so that it compiles correctly. And you should probably accept an answer to this question. – Jonathan Leffler Jun 16 '11 at 22:20

popen implicitly declared even though #include is added

4 Answers4

Linked

Related