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: Implement C11 annex K?

From: Paul Eggert <eggert at cs dot ucla dot edu>
To: "Joseph S. Myers" <joseph at codesourcery dot com>, Adhemerval Zanella <azanella at linux dot vnet dot ibm dot com>
Cc: libc-alpha at sourceware dot org
Date: Mon, 11 Aug 2014 08:51:57 -0700
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>

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 tryto use Annex K with _FILE_OFFSET_BITS=32.

Regardless of whether one thinks Annex K is a good idea, its stated goalis more-reliable software. Requiring it to support _FILE_OFFSET_BITS=32(which is deliberately *unreliable*) would be counterproductive make-work.

Follow-Ups:
- Re: Implement C11 annex K?
  - From: Joseph S. Myers

References:
- Implement C11 annex K?
  - From: David A. Wheeler
- Re: Implement C11 annex K?
  - From: Andreas Jaeger
- Re: Implement C11 annex K?
  - From: Adhemerval Zanella
- Re: Implement C11 annex K?
  - From: Joseph S. Myers

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