On 12/05/2013 10:25 AM, Paul Eggert wrote: > On 12/04/2013 11:51 AM, Paul Eggert wrote: >> or we can change the test case to not tickle the bug. > > I did the latter, as follows. Maybe at some point this > should be filed as a bug against glibc, since the bug occurs > even with _FORTIFY_SOURCE defined to 1 and that isn't supposed > to break conforming programs. > > --- > ChangeLog | 9 +++++++++ > tests/test-open.h | 11 ++++++++++- > 2 files changed, 19 insertions(+), 1 deletion(-)
Uggh - now I'm seeing a compilation warning in Cygwin and gcc 4.8.3: In file included from ../../gltests/test-open.c:35:0: ../../gltests/test-open.h:35:1: warning: always_inline function mingt not be inlinable [-Wattributes] test_open (int (*func) (char const *, int, ...), bool print) ^ > +/* Make test_open always inline if we're using Fortify, which defines > + __always_inline to do that. Do nothing otherwise. This works > + around a glibc bug whereby 'open' cannot be used as a function > + pointer when _FORTIFY_SOURCE is positive. */ > + > +#ifndef __always_inline > +#define __always_inline > +#endif On cygwin, __always_inline is unconditionally defined as __attribute__((__always_inline__)), and there is no _FORTIFY_SOURCE. I'm wondering if it will suffice to make this macro depend on whether _FORTIFY_SOURCE is defined. -- Eric Blake eblake redhat com +1-919-301-3266 Libvirt virtualization library http://libvirt.org
signature.asc
Description: OpenPGP digital signature
