Bug 14530 - __extern_always_inline is not always defined but stdlib.h may use it nevertheless
Summary: __extern_always_inline is not always defined but stdlib.h may use it neverthe...
Status: RESOLVED FIXED
Alias: None
Product: glibc
Classification: Unclassified
Component: libc (show other bugs)
Version: unspecified
: P2 normal
Target Milestone: ---
Assignee: Marek Polacek
URL:
Keywords: glibc_2.16
Depends on:
Blocks:
 
Reported: 2012-08-29 17:43 UTC by Dmitry V. Levin
Modified: 2014-06-17 04:48 UTC (History)
2 users (show)

See Also:
Host:
Target:
Build:
Last reconfirmed:
fweimer: security-


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Dmitry V. Levin 2012-08-29 17:43:08 UTC
Commit glibc-2.15-685-g5ac3ea1 introduced a regression:

$ echo '#include <stdlib.h>' |gcc-4.1 -O2 -D_FORTIFY_SOURCE=2 -S -xc++ - -o/dev/null
/usr/include/bits/stdlib.h:36: error: expected constructor, destructor, or type conversion before 'char'
/usr/include/stdlib.h:972: error: expected `}' at end of input

$ echo '#include <stdlib.h>' |gcc-4.1 -O2 -D_FORTIFY_SOURCE=2 -E -xc++ - |grep -A1 __extern_always_inline |head -2
__extern_always_inline __attribute__ ((__warn_unused_result__)) char *
 realpath (const char *__restrict __name, char *__restrict __resolved) throw ()

That is, g++ < 4.3 in fortify mode no longer compiles stdlib.h.

The bug is somewhat similar to
http://sourceware.org/bugzill/show_bug.cgi?id=13741 but is not exactly the same.

There is one particular hunk of commit glibc-2.15-685-g5ac3ea1 that made the difference:
-#if __USE_FORTIFY_LEVEL > 0 && defined __extern_always_inline
+#if __USE_FORTIFY_LEVEL > 0 && defined __fortify_function
Before that change, there were no attempts to include bits/stdlib.h in case of using old g++ in fortify mode, but there were another chances to hit undefined __extern_always_inline (the last is the subject of #13741).

A proper definition of __extern_always_inline in sys/cdefs.h would fix both bugs.
Comment 1 Marek Polacek 2012-08-29 17:48:52 UTC
Mine.
Comment 2 Marek Polacek 2012-09-26 11:02:10 UTC
Should be fixed by b7bfe116.