Eric Blake wrote:
> On 03/02/2011 10:10 AM, Paul Eggert wrote:
>> On 03/02/2011 07:09 AM, Jim Meyering wrote:
>>> - struct argv_iterator *ai = malloc (sizeof *ai);
>>> + struct argv_iterator *ai;
>>> + struct stat st;
>>> +
>>> + if (fstat (fileno (fp),&st) == 0&& S_ISDIR (st.st_mode))
>>> + {
>>> + errno = EISDIR;
>>> + return NULL;
>>> + }
>>> +
>>> + ai = malloc (sizeof *ai);
>>
>> My kneejerk reaction is that this part of the patch
>> should not be needed (though other fixes obviously are).
>> There are lots of reasons that the stream could fail:
>> why check for directories specially?
>
> Because other GNU apps do so? For example, POSIX requires that input
> files to m4 must be text files. If you do 'm4 dir/', you are therefore
That's fine for m4, but the --files0-from argument
is a file containing NUL-delimited file names: not a text file.
And obviously not covered by POSIX, besides.
However, my primary motivation was this: if we special-case
directories, should we also special-case char- and block-devices?
That seems inappropriate.
> violating POSIX, because dir/ is not a text file. However, I've chosen
> to make m4 uniformly fail with EISDIR on opening the file, rather than
> deal with the vaguaries of different platforms (some forbid
> fopen("dir/"), although that is in itself a POSIX violation; most get
> past the fopen(), but then it's arbitrary whether the fread() sees EOF,
> reads garbage, or fails with EISDIR). See:
> http://lists.gnu.org/archive/html/m4-patches/2008-09/msg00004.html
> http://git.savannah.gnu.org/cgit/m4.git/commit?id=eed62f0d
>
>> Just let the
>> stream fail in the way that it normally would; this
>> keeps the code smaller and simpler. On an ancient
>> host where "cat dir/" works, "du --files0-from=dir/"
>> should not arbitrarily fail.
>
> Yes, the code would be simpler by letting the directory do what it
> normally does (be that nothing, error, or raw data), but in the case of
> raw data, acting on that garbage is likely to lead to a host of other
> error messages.
