[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
signature.asc
Description: OpenPGP digital signature
- Re: [PATCH] test-open: avoid compilation error with -D_FORTIFY_SOURCE=2,
Eric Blake <=