SM Ryan said:
Because if it used popen() you would complain that it is not ANSI C.
['#' --> '>', as usual]
If it used popen() I would complain that it was posted to the wrong
newsgroup (comp.lang.c rather than comp.unix.programmer).
As it is, I'm complaining that it's non-portable *and* needlessly
inefficient and error-prone. It's inappropriate for any newsgroup
that doesn't deal with Unix-like systems because it depends on
Unix-specific features. If it appeared on comp.unix.programmer, I'd
complain about using a temp file rather than popen().
The code given be made into working ANSI C conforming code despite the
many false claims that it could not be done in ANSI C.
Sure, it's conforming code in that it's going to compile, even on a
Windows or DS9000 system. It's non-portable in that it makes
implementation-specific assumptions about the argument to system().
. an improvement).
Those of us used to working all multiple systems know how to deal with this.
The usual way is to have several different versions of the code,
either by having multiple versions of the same file, or using
conditional compilation, or generating the source file from a
template. I'm sure there are other ways. None of them require using
a temporary file rather than popen() for the sake of ANSI C
compliance.
The fact is, there is no way in portable standard C to determine the
size of a directory, but there are many ways to do it non-portably.
Some non-portable techniques are better than others.