GNU bug report logs - #21827
Large file support

Previous Next

Package: grep;

Reported by: Michael Brunnbauer <brunni <at> netestate.de>

Date: Wed, 4 Nov 2015 16:26:01 UTC

Severity: normal

Done: Paul Eggert <eggert <at> cs.ucla.edu>

Bug is archived. No further changes may be made.

Full log


Message #20 received at 21827 <at> debbugs.gnu.org (full text, mbox):

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: Eric Blake <eblake <at> redhat.com>, Michael Brunnbauer <brunni <at> netestate.de>, 
 21827 <at> debbugs.gnu.org
Subject: Re: bug#21827: Large file support
Date: Thu, 5 Nov 2015 18:47:18 -0800
Eric Blake wrote:
> Can't we probe for the existence of openat64(), and then probe whether
> the bug exists, and if so, replace openat() for that platform?

If one built with glibc 2.21 the probe would report no problem, with the failure 
occurring only when one ran the prebuilt executable, dynamically linked with 
glibc 2.22.  Possibly we could work around the bug at run-time, by falling back 
on syscall when openat fails with errno == EOVERFLOW, when compiled with glibc 
2.22 or earlier.  It's not the sort of code I'd like to write or test or 
maintain, though -- syscall is so machine-dependent.

>> >The bug was introduced on 2015-06-04 and fixed on 2015-08-10 in glibc.
> I guess it depends on whether we think these flawed versions are common
> in the wild, or whether vendors have patched the major distros and only
> self-built glibc remains vulnerable, on whether it is worth our effort.

Yes, that's exactly it. In the past we've sometimes worked around these bugs and 
sometimes not; it's a judgment call.  My guess is that the bug is so severe and 
affects so many apps that it'll get fixed pretty quickly in the wild.




This bug report was last modified 9 years and 206 days ago.

Previous Next


GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.