[Bug libc/17266] Always defining __extern_always_inline may generate infinite recursion

["cvs-commit at gcc dot gnu.org" <sourceware-bugzilla at sourceware dot org>]

https://sourceware.org/bugzilla/show_bug.cgi?id=17266

--- Comment #4 from cvs-commit at gcc dot gnu.org <cvs-commit at gcc dot gnu.org> ---
This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project "GNU C Library master sources".

The branch, master has been updated
       via  884ddc5081278f488ef8cd49951f41cfdbb480ce (commit)
      from  a7b872687073decdcc7effc2289877d69058aca9 (commit)

Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.

- Log -----------------------------------------------------------------
https://sourceware.org/git/gitweb.cgi?p=glibc.git;h=884ddc5081278f488ef8cd49951f41cfdbb480ce

commit 884ddc5081278f488ef8cd49951f41cfdbb480ce
Author: Siddhesh Poyarekar <siddhesh@redhat.com>
Date:   Tue Sep 16 14:08:48 2014 +0530

    Revert to defining __extern_inline only for gcc-4.3+ (BZ #17266)

    The check for only __GNUC_STDC_INLINE__ and __GNUC_GNU_INLINE__ may
    not be sufficient since those flags were added during initial support
    for C99 inlining semantics.  There is also a problem with always
    defining __extern_inline and __extern_always_inline, since it enables
    inline wrapper functions even when GNU inlining semantics are not
    guaranteed.  This, along with the possibility of such wrappers using
    redirection (btowc for example) could result in compiler generating an
    infinitely recusrive call to the function.

    In fact it was such a recursion that led to this code being written
    the way it was; see:

    https://bugzilla.redhat.com/show_bug.cgi?id=186410

    The initial change was to fix bugs 14530 and 13741, but they can be
    resolved by checking if __fortify_function and/or
    __extern_always_inline are defined, as it has been done in this patch.
    In addition, I have audited uses of __extern_always_inline to make
    sure that none of the uses result in compilation errors.

    There is however a regression in this patch for llvm, since it reverts
    the llvm expectation that __GNUC_STDC_INLINE__ or __GNUC_GNU_INLINE__
    definition imply proper extern inline semantics.

    2014-09-16  Siddhesh Poyarekar  <siddhesh@redhat.com>
            Jakub Jelinek  <jakub@redhat.com>

        [BZ #17266]
        * libio/stdio.h: Check definition of __fortify_function
        instead of __extern_always_inline to include bits/stdio2.h.
        * math/bits/math-finite.h [__USE_XOPEN || __USE_ISOC99]: Also
        check if __extern_always_inline is defined.
        [__USE_MISC || __USE_XOPEN]: Likewise.
        [__USE_ISOC99] Likewise.
        * misc/sys/cdefs.h (__fortify_function): Define only if
        __extern_always_inline is defined.
        [!__cplusplus || __GNUC_PREREQ (4,3)]: Revert to defining
        __extern_always_inline and __extern_inline only for g++-4.3
        and newer or a compatible gcc.

-----------------------------------------------------------------------

Summary of changes:
 ChangeLog               |   16 ++++++++++++++++
 libio/stdio.h           |    2 +-
 math/bits/math-finite.h |    8 +++++---
 misc/sys/cdefs.h        |   21 +++++++++++----------
 4 files changed, 33 insertions(+), 14 deletions(-)

-- 
You are receiving this mail because:
You are on the CC list for the bug.