This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [RFC] Make _FILE_OFFSET_BITS=64 default.


On Wed, Mar 19, 2014 at 02:50:35AM -0400, Mike Frysinger wrote:
> On Wed 19 Mar 2014 02:03:11 Rich Felker wrote:
> > On Wed, Mar 19, 2014 at 01:53:11AM -0400, Mike Frysinger wrote:
> > > On Fri 14 Mar 2014 14:18:37 Rich Felker wrote:
> > > > On Thu, Mar 13, 2014 at 11:41:48PM -0700, Paul Eggert wrote:
> > > > > glibc's own fts.h refuses to compile if __USE_FILE_OFFSET64 is
> > > > > defined.
> > > > 
> > > > Known issue:
> > > > https://sourceware.org/bugzilla/show_bug.cgi?id=15838
> > > > 
> > > > As stated there, my preference would be deprecation this whole API.
> > > > Applications which need it can get a _working_ (unlike the glibc copy)
> > > > version of this functionality from third-party sources. Gnulib and BSD
> > > > both have working versions that don't have the 32-bit limitation.
> > > 
> > > so wouldn't the right answer be to import the latest gnulib version ?
> > 
> > No, because the ABI is incompatible with glibc's interface. The reason
> > glibc is stuck with the broken one and gnulib isn't is that glibc has
> > to maintain an ABI while gnulib doesn't.
> 
> err, no it doesn't.  that's the entire point of versioned symbols.  glibc is 
> only restricted in maintaining past ABI compatibility, not being stuck with 
> crap for the whole future.
> 
> fork the existing fts symbols off and create brand new ones with GLIBC_2.20 
> versions and you're done.

Just doing it that way, the new interfaces would be incompatible with
-D_FILE_OFFSET_BITS=32. If symbol versioning is going to play a role
in solving this problem, I don't think it should be done to just one
odd-ball interface like fts, but as a global solution. That would
entail dropping support for 32-bit off_t, making all of the old 32-bit
functions accessible only via old symbol versions, and putting new
64-bit versions in front of them. This would of course simplify the
headers a lot; all of the redirection mess could be removed. I'm all
in favor of this solution, but it has a snowball's chance in hell of
being accepted by everybody else, so...

Rich


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]