This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: Implement C11 annex K?
- From: "Joseph S. Myers" <joseph at codesourcery dot com>
- To: Paul Eggert <eggert at cs dot ucla dot edu>
- Cc: Adhemerval Zanella <azanella at linux dot vnet dot ibm dot com>, <libc-alpha at sourceware dot org>
- Date: Mon, 11 Aug 2014 16:06:12 +0000
- Subject: Re: Implement C11 annex K?
- Authentication-results: sourceware.org; auth=none
- References: <E1XGDcM-0004tT-8P at rmm6prod02 dot runbox dot com> <53E724B6 dot 3000608 at suse dot com> <53E789C0 dot 4000109 at linux dot vnet dot ibm dot com> <Pine dot LNX dot 4 dot 64 dot 1408111511080 dot 23898 at digraph dot polyomino dot org dot uk> <53E8E69D dot 6090705 at cs dot ucla dot edu>
On Mon, 11 Aug 2014, Paul Eggert wrote:
> Joseph S. Myers wrote:
> > * Some functions will need versions for _FILE_OFFSET_BITS=64 /
> > _LARGEFILE64_SOURCE (e.g. tmpfile, fopen, freopen have such versions, so
> > the _s variants of those functions should also have such versions).
>
> Also, don't provide _FILE_OFFSET_BITS=32 versions. Just support
> _FILE_OFFSET_BITS=64, and make it a compile- or link-time error to try to use
> Annex K with _FILE_OFFSET_BITS=32.
>
> Regardless of whether one thinks Annex K is a good idea, its stated goal is
> more-reliable software. Requiring it to support _FILE_OFFSET_BITS=32 (which
> is deliberately *unreliable*) would be counterproductive make-work.
One goal is retrofitting large bodies of existing code with local changes
(for which adding a requirement to use _FILE_OFFSET_BITS=64 seems
unhelpful).
--
Joseph S. Myers
joseph@codesourcery.com