[RFC] Make _FILE_OFFSET_BITS=64 default.

Joseph S. Myers wrote:

> I certainly don't think they should be overriding _Static_assert provided by GCC (>= 4.6)

Good point, thanks.  Revised patches attached.

> I don't think the installed glibc headers should be providing _Static_assert

It's what FreeBSD <sys/cdefs.h> does, and applications seem to be doing 
fine there.  So there's good precedent, it's not risky, and it would 
improve compatibility with FreeBSD.

> arguably assert.h should try to do something for the case
> of _ISOC11_SOURCE, non-C11 compiler

That wouldn't support one of the main attractions of _Static_assert, 
namely that it works even when <assert.h> isn't included.  Application 
writers will prefer this feature, and defining _Static_assert in cdefs.h 
gets us close enough to this goal to be reasonably useful in apps 
compiled with pre-C11 compilers.

> generally that applies to any compiler possibly providing
> _Static_assert outside C11 mode - the library shouldn't get in the way of
> the user using the compiler feature

In general that's a good principle, but here there's not much to get in 
the way of, as the glibc substitute does the job even when it takes over 
from Clang etc.  If there's consensus I could add the usual forest of 
#ifs so as to not #define _Static_assert in non-GCC pre-C11 compilers 
where _Static_assert is known to work, but that's not what we've done in 
similar situations elsewhere in glibc, and there is some virtue in 
simplicity.
From 45c96ea279e95aa499856f9062f743665fd564ee Mon Sep 17 00:00:00 2001
From: Paul Eggert <eggert@cs.ucla.edu>
Date: Wed, 19 Mar 2014 10:59:31 -0700
Subject: [PATCH 1/2] Approximate _Static_assert for pre-C11 compilers.

* misc/sys/cdefs.h (_Static_assert) [__STDC_VERSION__ < 201112L]:
New macro, for convenience with pre-C11 compilers.
---
 ChangeLog        | 6 ++++++
 misc/sys/cdefs.h | 7 +++++++
 2 files changed, 13 insertions(+)

There's another problem with using such an assertion in fts.h: it's not 
the correct condition for the two ABIs to be the same.  On MIPS n64, 
struct stat and struct stat64 have different layout and so 
_FILE_OFFSET_BITS=64 is an ABI change despite __off_t and __off64_t having 
the same size (and part of the public fts interface is a pointer to struct 
stat).

On Thu, Mar 20, 2014 at 01:46:15AM +0000, Joseph S. Myers wrote:
> There's another problem with using such an assertion in fts.h: it's not 
> the correct condition for the two ABIs to be the same.  On MIPS n64, 
> struct stat and struct stat64 have different layout and so 
> _FILE_OFFSET_BITS=64 is an ABI change despite __off_t and __off64_t having 
> the same size (and part of the public fts interface is a pointer to struct 
> stat).

This is beyond disgusting; why was something like that ever allowed
into the ABI, rather than just using the stat64 struct/syscall (or
whichever one is saner) regardless of whether the stat or stat64
userspace function is called?

Rich

On Thu, 20 Mar 2014, Rich Felker wrote:

> On Thu, Mar 20, 2014 at 01:46:15AM +0000, Joseph S. Myers wrote:
> > There's another problem with using such an assertion in fts.h: it's not 
> > the correct condition for the two ABIs to be the same.  On MIPS n64, 
> > struct stat and struct stat64 have different layout and so 
> > _FILE_OFFSET_BITS=64 is an ABI change despite __off_t and __off64_t having 
> > the same size (and part of the public fts interface is a pointer to struct 
> > stat).
> 
> This is beyond disgusting; why was something like that ever allowed
> into the ABI, rather than just using the stat64 struct/syscall (or
> whichever one is saner) regardless of whether the stat or stat64
> userspace function is called?

This predates my maintaining the MIPS port, and long predates notions of 
carefully choosing the best ABI, hopefully architecture-independent, 
rather than having an ABI that at least approximately follows some other 
Unix for that architecture.  (I don't know if this particular ABI 
peculiarity - a userspace-only peculiarity, there's only one set of n64 
syscalls - arises from an attempt to be IRIX-compatible, but some 
peculiarities do.)