[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Hans-Bernhard Bröker
Subject: Re: fopen()-pclose() bug in install-info
Date: Wed, 10 Feb 2021 00:47:35 +0100
User-agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.7.0

Am 09.02.2021 um 21:55 schrieb Gavin Smith:

> 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.

I'm pretty sure it's 2d03d088d945a9dc0dd9318a32fe4e74ca51dfbc that broke this. Before, all fopen()s in there were freopen( , , stdin) calls. I.e. in the case of a non-compressed file, 'f' would be equal to stdin at all times. Only for detected compressed files would it then be overwritten by a popen()ed one. The change turned all those freopens to plain fopen(), and failed to add one back in for the non-compressed file case. So open_possibly_compressed_file() now doesn't match it's documented behaviour.

> One way to fix it would be reinstate the is_pipe argument and
> only call pclose if it's a pipe.

No need for an additional argument. The "compression program" output parameter already holds that information:

        if (*compression_program)

reply via email to

[Prev in Thread] Current Thread [Next in Thread]