On 16/06/15 13:47, Eric Blake wrote:
> [adding bug-gnulib]
>
> On 06/16/2015 06:28 AM, Johannes Meixner wrote:
>>
>>> From one of our (SUSE) kernel developers
>> I even got a proposal for a workaround in grep:
>>
>> --- a/src/grep.c
>> +++ b/src/grep.c
>> @@ -575,6 +575,17 @@ file_textbin (char *buf, size_t size, in
>> off_t hole_start = lseek (fd, cur, SEEK_HOLE);
>> if (0 <= hole_start)
>> {
>> + /* if hole_start is identical with cur, it's more likely a
>> buggy
>> + * lseek(SEEK_HOLE) implementation in kernel filesystem;
>> + * check whether it really reads a null byte.
>> + */
>> + if (hole_start == cur)
>> + {
>> + char c;
>> + if (read (fd, &c, 1) != 1 || c != 0)
>> + hole_start = st->st_size; /* no hole */
>> + }
>> +
>
> Sounds like we need to update the gnulib lseek module to work around
> bugs like this in the wild.
Interesting. The above runtime check wouldn't be appropriate I think
for such an old fleeting problem. Also the read() as a side effect
would be very much best avoided. How about a linux kernel version check
at build time?
As a general point, gnulib would really benefit from SEEK_HOLE, SEEK_DATA
wrappers that degenerated to SEEK_END,0 and SEEK_SET,offset respectively.
cheers,
Pádraig.
