GCC 4.4.3 Implicit Declaration of Popen/Pclose (MINIX 3.1.8)

[pikpik]

Hi,

As part of porting a library, I was testing the availability of the
"popen" and "pclose" C functions in MINIX 3.1.8 using GCC 4.4.3. I
adapted code from the "IEEE Std 1003.1, 2004 Edition" [1], and found
that on Mac OS X (10.5.8) with GCC 4.0.1 [2] there were no problems
compiling the test code while on MINIX there were some warnings.
However, on both platforms the compiled program ran without problems.
Listed below are the Problem, Test code, GCC version, and Related
information.

Problem:

# gcc popen-pclose-problem.c -o popen-pclose-problem -Wall

popen-pclose-problem.c: In function 'main':
popen-pclose-problem.c:13: warning: implicit declaration of function
'popen'
popen-pclose-problem.c:13: warning: assignment makes pointer from
integer without a cast


Test code:

# cat popen-pclose-problem.c

#include <stdio.h>

#define PATH_MAX 255


int main ( void ) {

FILE *filepipe;

char path [ PATH_MAX ];


filepipe = popen( "ls *", "r" );


if ( filepipe == NULL )
/* Handle error */ printf ( "The filepipe is NULL." );


while ( fgets ( path, PATH_MAX, filepipe ) != NULL )
printf ( "%s", path );


return 0;
}


GCC version:

# gcc --v

Using built-in specs.
Target: i686-pc-minix
Configured with: /usr/tmp/work/lang/gcc44/work/gcc-4.4.3/configure --
disable-nls --with-as=/usr/pkg/bin/as --with-ld=/usr/pkg/bin/ld --
prefix=/usr/pkg/gcc44 --enable-languages='c c++' --with-system-zlib --
enable-__cxa_atexit --enable-long-long --with-local-prefix=/usr/pkg/
gcc44 --disable-libssp --with-gmp=/usr/pkg --with-mpfr=/usr/pkg
Thread model: single
gcc version 4.4.3 (GCC)


Related Information:

[1] - IEEE Std 1003.1, 2004 Edition. <
http://pubs.opengroup.org/onlinepubs/009695399/functions/popen.html >

[2] - Mac OS X (10.5.8) with GCC 4.0.1 version:

% gcc --v

Using built-in specs.
Target: i686-apple-darwin9
Configured with: /var/tmp/gcc/gcc-5493~1/src/configure --disable-
checking -enable-werror --prefix=/usr --mandir=/share/man --enable-
languages=c,objc,c++,obj-c++ --program-transform-name=/^[cg][^.-]*$/s/
$/-4.0/ --with-gxx-include-dir=/include/c++/4.0.0 --with-slibdir=/usr/
lib --build=i686-apple-darwin9 --with-arch=apple --with-tune=generic --
host=i686-apple-darwin9 --target=i686-apple-darwin9
Thread model: posix
gcc version 4.0.1 (Apple Inc. build 5493)

Thank you,
pikpik

[Gautam B.T.]

>
> # gcc popen-pclose-problem.c -o popen-pclose-problem -Wall
>

Missing -D_POSIX_SOURCE flag?

--
Gautam

[Antoine LECA]

pikpik wrote:
> As part of porting a library, I was testing the availability of the
> "popen" and "pclose" C functions in MINIX 3.1.8 using GCC 4.4.3. I
> adapted code from the "IEEE Std 1003.1, 2004 Edition" [1], and found
> that on Mac OS X (10.5.8) with GCC 4.0.1 [2] there were no problems
> compiling the test code while on MINIX there were some warnings.
> However, on both platforms the compiled program ran without problems.
> Listed below are the Problem, Test code, GCC version, and Related
> information.
>
> Problem:
>
> # gcc popen-pclose-problem.c -o popen-pclose-problem -Wall
>
> popen-pclose-problem.c: In function 'main':
> popen-pclose-problem.c:13: warning: implicit declaration of function
> 'popen'

Bzzz !
On MINIX, as mandated by the POSIX standard when read strictly, if you
want to compile POSIX stuff you /need/ to use the correct instructions,
which is to #define _POSIX_SOURCE.
Not doing so is like using the compiler is strict ANSI C mode, and
popen() is not part of the ISO C standard, it is a POSIX "extension".

GCC by default has a different idea of how to use a compiler, and
consider the base mode is "full extended, including non-standard ones"
(i.e., #define _GNU_SOURCE). Issuing gcc -ansi (hence #defining
_STRICT_ANSI_) is a way to be more standard compliant, and is
recommended practice, particularly if you are using other compilers
besides GCC: conversely, not doing so obviously restricts portability.

As a result, please redo the test using
$ gcc -ansi -D_POSIX_SOURCE -Wall -Wextra <blablabla>

> #define PATH_MAX 255

Hmmmm... _MAX and _MIN are reserved suffixes under the POSIX standard
when the <limits.h> header is included, which could happen indirectly;
as a result, basically you cannot use them.

Moreover, with POSIX, PATH_MAX is indeed defined when you #include
<limits.h>: so you really should #include it instead of trying to guess
the value du jour...

Antoine

[pikpik]

Hi,

On Mar 9, 12:34 am, Gautam B.T. wrote:

> > # gcc popen-pclose-problem.c -o popen-pclose-problem -Wall

> Missing -D_POSIX_SOURCE flag?

Yes, that seems to do the trick. Thanks!

On Mar 9, 5:34 am, Antoine LECA wrote:

> pikpik wrote:

> > # gcc popen-pclose-problem.c -o popen-pclose-problem -Wall

> > popen-pclose-problem.c: In function 'main':
> > popen-pclose-problem.c:13: warning: implicit declaration of function
> > 'popen'

> Bzzz !
> On MINIX, as mandated by the POSIX standard when read strictly, if you
> want to compile POSIX stuff you /need/ to use the correct instructions,
> which is to #define _POSIX_SOURCE.
> Not doing so is like using the compiler is strict ANSI C mode, and
> popen() is not part of the ISO C standard, it is a POSIX "extension".

I'm not sure, but would it be odd then that compiling without "-
D_POSIX_SOURCE" (and seeing the warnings) still produces a functional
executable?

> GCC by default has a different idea of how to use a compiler, and
> consider the base mode is "full extended, including non-standard ones"
> (i.e., #define _GNU_SOURCE). Issuing gcc -ansi (hence #defining
> _STRICT_ANSI_) is a way to be more standard compliant, and is
> recommended practice, particularly if you are using other compilers
> besides GCC: conversely, not doing so obviously restricts portability.

> As a result, please redo the test using
> $ gcc -ansi -D_POSIX_SOURCE -Wall -Wextra <blablabla>

Ok.

> > #define PATH_MAX 255

> Hmmmm... _MAX and _MIN are reserved suffixes under the POSIX standard
> when the <limits.h> header is included, which could happen indirectly;
> as a result, basically you cannot use them.

> Moreover, with POSIX, PATH_MAX is indeed defined when you #include
> <limits.h>: so you really should #include it instead of trying to guess
> the value du jour...

Ah, sorry. I simply saw the code in the Open Group specification and
did not think to look any farther.

Thank you Antoine!

New code:

# cat popen-pclose-problem.c

#include <stdio.h>

#include <limits.h>

int main ( void ) {

FILE *filepipe;

char path [ PATH_MAX ];

filepipe = popen( "ls *", "r" );

if ( filepipe == NULL )
/* Handle error */ printf ( "The filepipe is NULL." );

while ( fgets ( path, PATH_MAX, filepipe ) != NULL )
printf ( "%s", path );

return 0;

}

New test line:

# gcc -ansi -D_POSIX_SOURCE -Wall -Wextra popen-pclose-problem.c -o
popen-pclose-problem
# _

As shown above, when the above code is compiled, there are no
warnings.

Thank you Gautam and Antoine!
pikpik

[Antoine LECA]

pikpik wrote:
> On Mar 9, 5:34 am, Antoine LECA wrote:
>> pikpik wrote:
>
>>> # gcc popen-pclose-problem.c -o popen-pclose-problem -Wall
>
>>> popen-pclose-problem.c: In function 'main':
>>> popen-pclose-problem.c:13: warning: implicit declaration of function
>>> 'popen'
>
>> Bzzz !
>> On MINIX, as mandated by the POSIX standard when read strictly, if you
>> want to compile POSIX stuff you /need/ to use the correct instructions,
>> which is to #define _POSIX_SOURCE.
>> Not doing so is like using the compiler is strict ANSI C mode, and
>> popen() is not part of the ISO C standard, it is a POSIX "extension".
>
> I'm not sure, but would it be odd then that compiling without

> "-D_POSIX_SOURCE" (and seeing the warnings) still produces a functional
> executable?

Why?
You are actually using functions beyond the ISO standard; since MINIX is
a POSIX-compliant system (or aims to), this is functional, no surprise
(it won't work as easily on say MS-DOS).

For the record: It is also so because of the legacy behaviour of
"K&R" C, without prototype, where calling functions without declarating
them before used to be the way to go. It is now considered bad-style,
but it still works (and allows to reuse old C programs seamlessly.)

Antoine

[pikpik]

Hi,

On Mar 10, 7:56 am, Antoine LECA wrote:
> pikpik wrote:
> > On Mar 9, 5:34 am, Antoine LECA wrote:
> >> On MINIX, as mandated by the POSIX standard when read strictly, if you
> >> want to compile POSIX stuff you /need/ to use the correct instructions,
> >> which is to #define _POSIX_SOURCE.
> >> Not doing so is like using the compiler is strict ANSI C mode, and
> >> popen() is not part of the ISO C standard, it is a POSIX "extension".
>
> > I'm not sure, but would it be odd then that compiling without
> > "-D_POSIX_SOURCE" (and seeing the warnings) still produces a functional
> > executable?
>
> Why?
> You are actually using functions beyond the ISO standard; since MINIX is
> a POSIX-compliant system (or aims to), this is functional, no surprise
> (it won't work as easily on say MS-DOS).

I suppose my expectations come from inexperience.

>
> For the record: It is also so because of the legacy behaviour of
> "K&R" C, without prototype, where calling functions without declarating
> them before used to be the way to go. It is now considered bad-style,
> but it still works (and allows to reuse old C programs seamlessly.)
>
> Antoine

Thank you for showing me this! The migrations from standard to
standard are very interesting, especially in a historic perspective.

It is likely irrelevant, but I find it quite interesting that a number
of scripting languages used today, such as PHP and JavaScript, allow a
calling functions at any point in a program while the functions'
definitions may also be placed anywhere in the program (except
functions defined globally are accessible globally while those defined
privately are usually only accessible privately, unless the functions
are passed between scopes as variables). In this way, I see either one
of two things: these newer languages follow deprecated styles perhaps
for interesting reasons or C could be moving towards and away from
dynamic traits in different ways.

Thank you,
pikpik

[Antoine LECA]

pikpik wrote:
> It is likely irrelevant, but I find it quite interesting that a number
> of scripting languages used today, such as PHP and JavaScript, allow a
> calling functions at any point in a program while the functions'
> definitions may also be placed anywhere in the program (except
> functions defined globally are accessible globally while those defined
> privately are usually only accessible privately, unless the functions
> are passed between scopes as variables). In this way, I see either one
> of two things: these newer languages follow deprecated styles perhaps
> for interesting reasons or C could be moving towards and away from
> dynamic traits in different ways.

In the 70's and most of the 80's, computer language engineering was
dominated by the principles of typed languages as typified by Pr.Niklaus
Wirth. Of course, there was an engineering reason too: in the beginning,
hardware was so much a factor that made efficiency a necessary
requirement, even for compilers.
So was born C, which was created as "B with types", that is, a derived
using then up-to-date technology, types. OTOH C was a "loosely" typed
language, and with its pointers it permitted many acrobatic standings
which was really needed to write operating systems. As we all know, this
was a huge success, because it was a good equilibrium and many people
went with it. The success was so great that C compiler are, with Fortran
ones and for the same reasons, still the most optimising: quite simply,
because it is where there is the market to do so.

As time passes, hardware get more and more cheaper and programmer time
became the most limiting factor, much more than efficiency of the
resulting programs. There are many ways to reduce programmers' time. One
is to reuse already existing programs, hence backward compatibility is a
very important goal (hence Fortran and C still relevant.) Another are
components, and as object-orientation has been declared as a way to
achieve that, so were C++, Java and their alikes, huge successes since
they capitalize on both points. To make the programmer more efficient
can also be done by using lighter toolchains, for example using
interpreters: and here we have Perl, Python, Javascript, PHP, Ruby.

Okay, now you can read theory; I would recommend N. Wirth's
http://www.inf.ethz.ch/personal/wirth/Articles/LeanSoftware.pdf (1995)

Antoine
__________
PS: before someone wants to point it: Undeclarative or OO languages are
not quite new: LISP or Smalltalk actually predate C.
But they completely lack C compatibility.

[pikpik]

Hi Antoine,

On Mar 14, 6:26 am, Antoine LECA wrote:
> pikpik wrote:
> > It is likely irrelevant, but I find it quite interesting that a number
> > of scripting languages used today, such as PHP and JavaScript, allow a
> > calling functions at any point in a program while the functions'
> > definitions may also be placed anywhere in the program (except
> > functions defined globally are accessible globally while those defined
> > privately are usually only accessible privately, unless the functions
> > are passed between scopes as variables). In this way, I see either one
> > of two things: these newer languages follow deprecated styles perhaps
> > for interesting reasons or C could be moving towards and away from
> > dynamic traits in different ways.
>
> In the 70's and most of the 80's, computer language engineering was
> dominated by the principles of typed languages as typified by Pr.Niklaus
> Wirth. Of course, there was an engineering reason too: in the beginning,
> hardware was so much a factor that made efficiency a necessary
> requirement, even for compilers.

This reminds me of our current distress at GCC's slow speed.

> So was born C, which was created as "B with types", that is, a derived
> using then up-to-date technology, types. OTOH C was a "loosely" typed
> language, and with its pointers it permitted many acrobatic standings
> which was really needed to write operating systems. As we all know, this
> was a huge success, because it was a good equilibrium and many people
> went with it.

It is interesting that Forth, while being very efficient by nature (at
least in theory), did not retain as much popularity as C.

> The success was so great that C compiler are, with Fortran
> ones and for the same reasons, still the most optimising: quite simply,
> because it is where there is the market to do so.

This is a very interesting point. I've seen it before, but I don't
understand how the market encourages optimization. Is it by providing
resources and interest in the further performance that encourages the
underlying research?

> As time passes, hardware get more and more cheaper and programmer time
> became the most limiting factor, much more than efficiency of the
> resulting programs. There are many ways to reduce programmers' time. One
> is to reuse already existing programs, hence backward compatibility is a
> very important goal (hence Fortran and C still relevant.) Another are
> components, and as object-orientation has been declared as a way to
> achieve that, so were C++, Java and their alikes, huge successes since
> they capitalize on both points. To make the programmer more efficient
> can also be done by using lighter toolchains, for example using
> interpreters: and here we have Perl, Python, Javascript, PHP, Ruby.

Unfortunately, I've noticed that some of the runtime engines for such
interpreted (or now bytecode or Just-In-Time compiled) languages are
increasingly heavy in their use of resources, memory especially.

> Okay, now you can read theory; I would recommend N. Wirth's
> http://www.inf.ethz.ch/personal/wirth/Articles/LeanSoftware.pdf (1995)

Wow, thank you! That was fascinating to read! It really illustrates
interesting things about Unix, MINIX, Forth (OS), C, and software
design and development as well as other really interesting topics.
(Could MINIX be fit into 8,000 KB [~8 MB would certainly be nice]? :D)
But it is seriously interesting. Perhaps Ada has some interesting
uses? Overall, I think many aspects of C, even while outlined as error-
prone, are very useful.

> Antoine
> __________
> PS: before someone wants to point it: Undeclarative or OO languages are
> not quite new: LISP or Smalltalk actually predate C.
> But they completely lack C compatibility.

Two interesting things about these facts are that a number of object-
oriented languages of today were influenced by those languages
(Smalltalk influenced the design of JavaScript) and that Objective-C
is referred as a superset of C extended to be object-oriented by
Smalltalk.

Thanks you very much!
pikpik