[uClibc]Thoughts on pclose()/popen()

[Manuel Novoa III]

On Wed, Dec 18, 2002 at 01:18:39PM +0100, Tobias Anderberg wrote:
> I was looking at the pclose() code in libc/stdio/popen.c and I
> came to realize that using wait() there might not be so good.
> Doesn't this mean that pclose waits for any child and not just
> the one created by popen?
> 
> In fact, the OpenGroup specification[1] says
> 
>   To conform to IEEE Std 1003.1-2001, pclose() must use 
>   waitpid(), or some similar function, instead of wait().
> 
> Came to think about it, wouldn't it be better if popen keep
> track of the child's pid, which then pclose simply wait on?
> 
> Hm. Looking at the glibc code it does exactly that.
> 
> Comments? Any reason for not changing the popen()/pclose() to
> the above? If not, I'll put it on my todo.

The use of wait() seems to be an artifact of the original implementation
in the dev86 libc code for ELKS (which doesn't have waitpid).

Fixing it will involve adding a pid field to the internal file struct,
which I'd prefer to take care of (since there are places where I
allocate and initialize a temporary FILE on the stack).

One thing I'm unsure of though is should the stdio cleanup code invoke
fclose() or pclose() at program termination if the app failed to do a
pclose() itself.  This is also a question with respect to the glibc
extension function fcloseall().  Thoughts anyone?

Manuel