Re: fopen()-pclose() bug in install-info

[Gavin Smith]

On Tue, Feb 09, 2021 at 10:02:47PM +0100, Barath Aron wrote:
> On 2/9/21 9:55 PM, Gavin Smith wrote:
> > On Tue, Feb 09, 2021 at 09:10:28PM +0100, Barath Aron wrote:
> > > The code path I wrote is the trace of the program, I didn't made it up. It
> > > first opened a regular, non-compressed file with fopen() [this was in line
> > > 700], then it would freopen()ed [line 882, but it won't make any
> > > difference], then closed the fopen()ed file with pclose() [line 939]. And
> > > per-definition, you can't pclose() a FILE opened with fopen(). It is
> > > undefined behavior, libc is "allowed" to wait for something which will not
> > > happen.
> > > POSIX spec says: "If the argument stream to pclose() is not a pointer to a
> > > stream created by popen(), the result of pclose() is undefined."
> > > So, on Linux and on some other OSs this case works by mistake, but it is 
> > > not
> > > required.
> > Yes, it is clearly wrong in this case.  It's just a question now of
> > understanding the changes in the two earlier commits and making
> > sure that we don't break anything that those commits were supposed to
> > fix.  One way to fix it would be reinstate the is_pipe argument and
> > only call pclose if it's a pipe.
> 
> Sounds good! The is_pipe argument would definitely solve the issue. My
> modification was really just a "make this thing work ASAP, better a resource
> leak than a hangup, until it is really fixed".

I've attempted a fix in commit c3cd8f03e.  I'm always nervous to make changes
like this.