JehanneOS/newlib
1
0
Fork 0
Code Issues Pull Requests Projects Releases Wiki Activity

* libc/include/stdio.h (_ELIDABLE_INLINE): Move definition from here...

Browse Source 
* libc/include/_ansi.h (_ELIDABLE_INLINE): ..to here.
This commit is contained in:
Corinna Vinschen 2009-04-04 15:44:19 +00:00
parent d74c61c2be
commit 56c5c08a5d
3 changed files with 27 additions and 22 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

5
newlib/ChangeLog
View File

@ -1,3 +1,8 @@
2009-04-04 Corinna Vinschen <corinna@vinschen.de>
* libc/include/stdio.h (_ELIDABLE_INLINE): Move definition from here...
* libc/include/_ansi.h (_ELIDABLE_INLINE): ..to here.
2009-04-03 Yaakov Selkowitz <yselkowitz@users.sourceforge.net>
* libc/include/stdio.h [__SCLE] (__sgetc_r): Prototype before define

21
newlib/libc/include/_ansi.h
View File

@ -79,6 +79,27 @@
#define _ATTRIBUTE(attrs)
#endif
/* The traditional meaning of 'extern inline' for GCC is not
to emit the function body unless the address is explicitly
taken. However this behaviour is changing to match the C99
standard, which uses 'extern inline' to indicate that the
function body *must* be emitted. If we are using GCC, but do
not have the new behaviour, we need to use extern inline; if
we are using a new GCC with the C99-compatible behaviour, or
a non-GCC compiler (which we will have to hope is C99, since
there is no other way to achieve the effect of omitting the
function if it isn't referenced) we just use plain 'inline',
which c99 defines to mean more-or-less the same as the Gnu C
'extern inline'. */
#if defined(__GNUC__) && !defined(__GNUC_STDC_INLINE__)
/* We're using GCC, but without the new C99-compatible behaviour. */
#define _ELIDABLE_INLINE extern __inline__ _ATTRIBUTE ((__always_inline__))
#else
/* We're using GCC in C99 mode, or an unknown compiler which
we just have to hope obeys the C99 semantics of inline. */
#define _ELIDABLE_INLINE __inline__
#endif
/* ISO C++. */
#ifdef __cplusplus

23
newlib/libc/include/stdio.h
View File

@ -589,28 +589,7 @@ FILE *_EXFUN(_fopencookie_r,(struct _reent *, void *__cookie,
There are two possible means to this end when compiling with GCC,
one when compiling with a standard C99 compiler, and for other
compilers we're just stuck. At the moment, this issue only
affects the Cygwin target, so we'll most likely be using GCC.
The traditional meaning of 'extern inline' for GCC is not
to emit the function body unless the address is explicitly
taken. However this behaviour is changing to match the C99
standard, which uses 'extern inline' to indicate that the
function body *must* be emitted. If we are using GCC, but do
not have the new behaviour, we need to use extern inline; if
we are using a new GCC with the C99-compatible behaviour, or
a non-GCC compiler (which we will have to hope is C99, since
there is no other way to achieve the effect of omitting the
function if it isn't referenced) we just use plain 'inline',
which c99 defines to mean more-or-less the same as the Gnu C
'extern inline'. */
#if defined(__GNUC__) && !defined(__GNUC_STDC_INLINE__)
/* We're using GCC, but without the new C99-compatible behaviour. */
#define _ELIDABLE_INLINE extern __inline__ _ATTRIBUTE ((__always_inline__))
#else
/* We're using GCC in C99 mode, or an unknown compiler which
we just have to hope obeys the C99 semantics of inline. */
#define _ELIDABLE_INLINE __inline__
#endif
affects the Cygwin target, so we'll most likely be using GCC. */
_ELIDABLE_INLINE int __sgetc_r(struct _reent *__ptr, FILE *__p);