bug-gnulib
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH] test-open: avoid compilation error with -D_FORTIFY_SOURCE=2


From: Eric Blake
Subject: Re: [PATCH] test-open: avoid compilation error with -D_FORTIFY_SOURCE=2
Date: Wed, 30 Jul 2014 16:11:13 -0600
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0

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

Attachment: signature.asc
Description: OpenPGP digital signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]