| Message ID | 532956D4.5020804@cs.ucla.edu |
|---|---|
| State | New |
| Headers | show |
On Wed 19 Mar 2014 01:35:32 Paul Eggert wrote: > Mike Frysinger wrote: > > so wouldn't the right answer be to import the latest gnulib version ? > > It's better to decouple the issue of altering fts.h from the issue of > the _FILE_OFFSET_BITS default. sure ... i don't plan on fts.h holding up my evil plans :) > Hardly anybody uses fts.h so this is no big deal. We could leave fts.h > alone; all that would happen if the _FILE_OFFSET_BITS default changes is > that in theory more compilations would fail, but there'd be no run-time > misbehavior. i recall seeing maybe two packages that used fts.h so far. but last time i looked was when i was running x86/32bit as my main desktop and used _FILE_OFFSET_BITS=64 in my own global build settings. > Better, we could install something like the attached patch, > independently of any change to the _FILE_OFFSET_BITS default. This > patch fixes the bug that one cannot do the following on a 64-bit host: > > #define _FILE_OFFSET_BITS 64 > #include <fts.h> > > which is an unnecessary restriction, as off_t is 64 bits anyway so > <fts.h> should work. If we install the attached patch and change the > _FILE_OFFSET_BITS default, the only fts.h compilations that would stop > working would be compilations on 32-bit hosts that don't set > _FILE_OFFSET_BITS to 32; that's good enough and is probably the least > intrusive change that we can easily do. i have gotten complaints in the past that glibc provided half-baked support for static assert when building with <gcc-4.6. so this would make those people happy too :). -mike
diff --git a/io/fts.h b/io/fts.h index 0a070ba..f71f550 100644 --- a/io/fts.h +++ b/io/fts.h @@ -35,10 +35,12 @@ #include <features.h> #include <sys/types.h> -/* The fts interface is incompatible with the LFS interface which - transparently uses the 64-bit file access functions. */ +/* When off_t is not 64 bits, the fts interface is incompatible with + the LFS interface which transparently uses the 64-bit file access + functions. */ #ifdef __USE_FILE_OFFSET64 -# error "<fts.h> cannot be used with -D_FILE_OFFSET_BITS==64" +_Static_assert (sizeof (__off_t) == sizeof (__off64_t), + "<fts.h> cannot be used with 64-bit off_t on this platform"); #endif diff --git a/misc/sys/cdefs.h b/misc/sys/cdefs.h index 4d958ea..ebf5588 100644 --- a/misc/sys/cdefs.h +++ b/misc/sys/cdefs.h @@ -382,6 +382,12 @@ # define __glibc_likely(cond) (cond) #endif +#if (!defined _Static_assert \ + && (!defined __STDC_VERSION__ || __STDC_VERSION__ < 201112L)) +# define _Static_assert(e, s) extern int (*__glibc_Static_assert (void)) \ + [sizeof (struct { unsigned int _error_if_negative: (e) ? 1 : -1; })] +#endif + #include <bits/wordsize.h> #if defined __LONG_DOUBLE_MATH_OPTIONAL && defined __NO_LONG_DOUBLE_MATH
Mike Frysinger wrote: > so wouldn't the right answer be to import the latest gnulib version ? It's better to decouple the issue of altering fts.h from the issue of the _FILE_OFFSET_BITS default. Hardly anybody uses fts.h so this is no big deal. We could leave fts.h alone; all that would happen if the _FILE_OFFSET_BITS default changes is that in theory more compilations would fail, but there'd be no run-time misbehavior. Better, we could install something like the attached patch, independently of any change to the _FILE_OFFSET_BITS default. This patch fixes the bug that one cannot do the following on a 64-bit host: #define _FILE_OFFSET_BITS 64 #include <fts.h> which is an unnecessary restriction, as off_t is 64 bits anyway so <fts.h> should work. If we install the attached patch and change the _FILE_OFFSET_BITS default, the only fts.h compilations that would stop working would be compilations on 32-bit hosts that don't set _FILE_OFFSET_BITS to 32; that's good enough and is probably the least intrusive change that we can easily do.