Red Hat Bugzilla – Bug 174043
netatalk/papd fails to close pipe correctly
Last modified: 2007-11-30 17:11:17 EST
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (compatible; MSIE 6.0; Windows; U; AIIEEEE!; Win98; Windows 98; en-US; Gecko masquerading as IE; should it matter?; rv:1.8b) Gecko/20050217
Description of problem:
The papd application fails to correctly close pipe.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1.read source file papd/lp.c
Actual Results: See that fclose is always invoked, even if it is a pipe.
Expected Results: Should be possibly using pclose.
From pclose manual entry:
"The return value from popen() is a normal standard I/O stream in all
respects save that it must be closed with pclose() rather than
Created attachment 121427 [details]
Corrects fclose on pipe
I'm not sure this is a good idea.
Closing the stream unconditionally with fclose() means that the reader process
will get a broken pipe error, ie. it knows that papd is finished with it.
pclose() on the other hand "waits for the associated process to terminate"
(man popen(3)) before closing the stream and returns the process exit status .
Perhaps lp programs could depend on the broken pipe error to know when input
is finished; if papd used pclose, it could wait forever for the reader to
There is no value in using pclose() rather than fclose() if you do not want to
wait for the program at the other end of the pipe to terminate.
Does this use of pclose fix any definite, reproducible problem ? If so, please
re-open this bug with details of how to reproduce, and I'll contact the upstream
maintainers to get their opinion on this issue.
(In reply to comment #2)
> I'm not sure this is a good idea.
That is an interesting conclusion. And an interesting discusssion about why
pclose() might not be a good idea.
Now, let's have a look at the glibc code for pclose:
int __new_pclose (FILE *fp)
return _IO_new_fclose (fp);
Do you see what I can see?