Hi popen() guru,

How to *correctly* compile a C code containing popen()?
I know that popen() is not an ANSI function.
I got some warnings while using gcc to compile the code:
[I have included #include<stdio.h> in the header.]

$gcc -ansi -Wall -pedantic test.c
test.c: In function `main':
test.c:9: warning: implicit declaration of function `popen'
test.c:9: warning: assignment makes pointer from integer without a cast
test.c:18: warning: implicit declaration of function `pclose'

Thank you,

pi

[ Post a follow-up to this message ]

"Pai-Yi Hsiao" <hsiao@ccr.jussieu.fr> wrote in message
news:c66f415c.0402271643.34fd2560@posting.google.com...
> I know that popen() is not an ANSI function.

Good.


> $gcc -ansi -Wall -pedantic test.c
> test.c: In function `main':
> test.c:9: warning: implicit declaration of function `popen'
> test.c:9: warning: assignment makes pointer from integer without a cast
> test.c:18: warning: implicit declaration of function `pclose'


Why are you specifying '-ansi'?

DS

[ Post a follow-up to this message ]

Pai-Yi Hsiao <hsiao@ccr.jussieu.fr> wrote:
> How to *correctly* compile a C code containing popen()?
> I know that popen() is not an ANSI function.
> I got some warnings while using gcc to compile the code:
> [I have included #include<stdio.h> in the header.]

> $gcc -ansi -Wall -pedantic test.c
> test.c: In function `main':
> test.c:9: warning: implicit declaration of function `popen'
> test.c:9: warning: assignment makes pointer from integer without a cast
> test.c:18: warning: implicit declaration of function `pclose'

The problem is that you tell the compiler to be real picky and barf
at all non-standard functions by using the -ansi and -pedantic flags.
But since popen() and pclose() aren't standard functions they won't
get declared in the headers in this case. So you either need to drop
that flags or you must have some additional defines. At least for the
system I am currently sitting at you need to #define either
__USE_POSIX2, __USE_SVID or __USE_BSD to get the declarations for
popen() and pclose(). Alternatively, you can declare them yourself.
as

extern FILE *popen( const char *command, const char *modes);
extern int pclose(FILE *stream);

Regards, Jens
--
\   Jens Thoms Toerring  ___  Jens.Toerring@physik.fu-berlin.de
\__________________________  http://www.toerring.de

[ Post a follow-up to this message ]

Jens.Toerring@physik.fu-berlin.de wrote:
>Pai-Yi Hsiao <hsiao@ccr.jussieu.fr> wrote: 
> 
>
>The problem is that you tell the compiler to be real picky and barf
>at all non-standard functions by using the -ansi and -pedantic flags.
>But since popen() and pclose() aren't standard functions they won't
>get declared in the headers in this case. So you either need to drop
>that flags or you must have some additional defines. At least for the
>system I am currently sitting at you need to #define either
>__USE_POSIX2, __USE_SVID or __USE_BSD to get the declarations for
>popen() and pclose(). Alternatively, you can declare them yourself.
>as
>
>extern FILE *popen( const char *command, const char *modes);
>extern int pclose(FILE *stream);

Ouch.  That's all the right idea, but not quite the the way to
do it.  Providing your own prototype/declaration is of course
possible, but it misses a great deal more than it catches, and
is rarely useful (which is to say Jens and others might well do
that and make do with only that, on occasion, but clearly the OP
will cause more problems than not by trying it).

As to #defines, the ones listed above are in the implementation's
name space, and should not be used.  Rather, there is a fair
description in /usr/include/features.h, which on a Linux system
says,

/* These are defined by the user (or the compiler)
to specify the desired environment:

__STRICT_ANSI__      ISO Standard C.
_ISOC99_SOURCE       Extensions to ISO C89 from ISO C99.
_POSIX_SOURCE        IEEE Std 1003.1.
_POSIX_C_SOURCE      If ==1, like _POSIX_SOURCE; if >=2 add IEEE Std 1003.2;
if >=199309L, add IEEE Std 1003.1b-1993;
if >=199506L, add IEEE Std 1003.1c-1995
_XOPEN_SOURCE        Includes POSIX and XPG things.  Set to 500 if
Single Unix conformance is wanted, to 600 for the
upcoming sixth revision.
_XOPEN_SOURCE_EXTENDED XPG things and X/Open Unix extensions.
_LARGEFILE_SOURCE    Some more functions for correct standard I/O.
_LARGEFILE64_SOURCE  Additional functionality from LFS for large files.
_FILE_OFFSET_BITS=N  Select default filesystem interface.
_BSD_SOURCE          ISO C, POSIX, and 4.3BSD things.
_SVID_SOURCE         ISO C, POSIX, and SVID things.
_GNU_SOURCE          All of the above, plus GNU extensions.
_REENTRANT           Select additionally reentrant object.
_THREAD_SAFE         Same as _REENTRANT, often used by other systems.

The `-ansi' switch to the GNU C compiler defines __STRICT_ANSI__.
If none of these are defined, the default is to have _SVID_SOURCE,
_BSD_SOURCE, and _POSIX_SOURCE set to one and _POSIX_C_SOURCE set to
199506L.  If more than one of these are defined, they accumulate.
For example __STRICT_ANSI__, _POSIX_SOURCE and _POSIX_C_SOURCE
together give you ISO C, 1003.1, and 1003.2, but nothing else.


Hence, a command line with -ansi -pedantic is just fine, even for
a program that includes unistd.h and makes use of the facilities
defined there.

The source code can have (as one example)

#define _BSD_SOURCE
#include <unistd.h>

Or one can provide the same definition to gcc from the command line

gcc -D _BSD_SOURCE -Wall -W -ansi -pedantic foo.c

Note also the added -W options for an increased level of warnings
from the compiler.

--
Floyd L. Davidson           <http://web.newsguy.com/floyd_davidson>
Ukpeagvik (Barrow, Alaska)                         floyd@barrow.com

[ Post a follow-up to this message ]

hsiao@ccr.jussieu.fr (Pai-Yi Hsiao) writes:

>Hi popen() guru,

>How to *correctly* compile a C code containing popen()?
>I know that popen() is not an ANSI function.

>$gcc -ansi -Wall -pedantic test.c

If you know that it's not an ANSI function why are you compiling
with "-ansi -pedantic"?

The ANSI and POSIX standards have certain rules about identifiers
that are defined in standard header files; you can't define any which are
not in the standard when compiling in conformant (aka "useless") mode.

Casper
--
Expressed in this posting are my opinions.  They are in no way related
to opinions held by my employer, Sun Microsystems.
Statements on Sun products included here are not gospel and may
be fiction rather than truth.

[ Post a follow-up to this message ]

Casper H.S. Dik <Casper.Dik@Sun.COM> wrote:
>hsiao@ccr.jussieu.fr (Pai-Yi Hsiao) writes:
> 
> 
> 
>
>If you know that it's not an ANSI function why are you compiling
>with "-ansi -pedantic"?

Probably because whether or not "popen" is an ANSI function is
virtually unrelated to the reason one would want the compiler to
assume, even pedantically per gcc, ansi code.

>The ANSI and POSIX standards have certain rules about identifiers
>that are defined in standard header files; you can't define any which are
>not in the standard when compiling in conformant (aka "useless") mode.

You can define identifiers which are not in the standard when
compiling in conformant mode (which /is/ a very useful mode),
and neither the ISO/ANSI nor the POSIX standards claim
otherwise.  (Yes including headers for libraries to which the
compiler does not have access to the source of does invoke
undefined behavior and make the program being compiled
technically nonconformant.  Which is itself a complex subject,
but not really of use to the OP.)

See the features.h include file.  The OP's problem has no direct
relationship to the ISO/ANSI standard, but rather is an
implementation detail of gcc and the header files it uses.

--
Floyd L. Davidson           <http://web.newsguy.com/floyd_davidson>
Ukpeagvik (Barrow, Alaska)                         floyd@barrow.com

[ Post a follow-up to this message ]

in comp.unix.programmer i read:
>hsiao@ccr.jussieu.fr (Pai-Yi Hsiao) writes:
 
> 
>
>If you know that it's not an ANSI function why are you compiling
>with "-ansi -pedantic"?

if you want this behavior (c89/90 compiler conformance but with extensions
in the libraries) you need to define specific macros, e.g., use
-D_XOPEN_SOURCE=500 for susv2 library conformance.  see the gcc and your
libc's documentation of the various `feature test macros' at your disposal.

--
a signature

[ Post a follow-up to this message ]

floyd@barrow.com (Floyd L. Davidson) writes:

>You can define identifiers which are not in the standard when
>compiling in conformant mode (which /is/ a very useful mode),
>and neither the ISO/ANSI nor the POSIX standards claim
>otherwise.


I claim but one thing: IF you include a <include.h> file
which is defined in the standard the implementation is NOT allowed to
defined ANY other identifiers in those files than those defined in
the standards when compiling in comformant mode (which is the only
thing the standard concerns itself with)

I.e., ANSI *forbids* the declaration of popen() in <stdio.h>.

There are a few exceptions to this rule (implementation reserved namespace)
but the user's namespace is sacred.

The reasoning begin this is fairly simple:


#include <stdio.h>


int popen(void)
{
static int pope;

return (pope++);
}

int
main(void)
{
exit(popen);
}

Is a conformant ANSI C program.

It will not compile if "FILE *popen(const char *)" is made visible
in <stdio.h>.

Casper
--
Expressed in this posting are my opinions.  They are in no way related
to opinions held by my employer, Sun Microsystems.
Statements on Sun products included here are not gospel and may
be fiction rather than truth.

[ Post a follow-up to this message ]