bug#11424: coreutils: split tests hang on /dev/zero on GNU/Hurd

[Jim Meyering]

Jim Meyering wrote:
> Paul Eggert wrote:
>> On 05/07/2012 12:46 AM, Jim Meyering wrote:
>>> +
>>> +  /* stat.st_size is valid only for regular files.  For others, use 0.  */
>>> +  file_size = S_ISREG (stat_buf.st_mode) ? stat_buf.st_size : 0;
>>
>> Is it right to use 0 there, for non-regular files?
>> Won't later code compute incorrect sizes in that case?
>
> Hi Paul,
>
> I agree that more change is required and do prefer the direction your
> patches suggest.  However, to fix the Hurd/infloop with minimal
> impact elsewhere, I have a slight preference for my small change.
> I.e. continuing to operate on non-regular files with --number we
> don't have to change the split --number tests that operate on /dev/zero.
> Then, introducing the behavior change (with your follow-on patch) can
> be independent of the bug fix commit.
>
> I do admit that without being able to determine a size up front, there's
> little point in using that option, so your patch (reject files with
> unusable stat.st_size) is required.
>
> With or without my patch on Linux/GNU, if you split /dev/zero,
> it sets file_size = 0, so at least for the tested cases
> I don't think that patch introduces a regression.
>
>> Also, as a nit, stat.st_size is also valid for
>> SHM and TMO files (this was in the patch I just sent).
>
> Good point.
> Do you feel like adding something like this to system.h
> and completing your patch?
>
>     /* Return a boolean indicating whether sb->st_size is defined.  */
>     static inline bool
>     usable_st_size (struct stat const *sb)
>     {
>       return S_ISREG (sb->st_mode) || S_TYPEISSHM (sb) || S_TYPEISTMO (sb);
>     }

I went ahead and pushed the less-invasive fix.
Your behavior-changing one is more than welcome, too.