supported by the compiler. If the compiler does not support this
feature, the macro expands to an unused extern declaration.
- This macro is useful for marking a function as a potential
+ _GL_WARN_ON_USE_ATTRIBUTE ("literal string") expands to the
+ attribute used in _GL_WARN_ON_USE. If the compiler does not support
+ this feature, it expands to empty.
+
+ These macros are useful for marking a function as a potential
portability trap, with the intent that "literal string" include
instructions on the replacement function that should be used
- instead. However, one of the reasons that a function is a
- portability trap is if it has the wrong signature. Declaring
- FUNCTION with a different signature in C is a compilation error, so
- this macro must use the same type as any existing declaration so
- that programs that avoid the problematic FUNCTION do not fail to
- compile merely because they included a header that poisoned the
- function. But this implies that _GL_WARN_ON_USE is only safe to
- use if FUNCTION is known to already have a declaration. Use of
- this macro implies that there must not be any other macro hiding
- the declaration of FUNCTION; but undefining FUNCTION first is part
- of the poisoning process anyway (although for symbols that are
- provided only via a macro, the result is a compilation error rather
- than a warning containing "literal string"). Also note that in
- C++, it is only safe to use if FUNCTION has no overloads.
+ instead.
+ _GL_WARN_ON_USE is for functions with 'extern' linkage.
+ _GL_WARN_ON_USE_ATTRIBUTE is for functions with 'static' or 'inline'
+ linkage.
+
+ However, one of the reasons that a function is a portability trap is
+ if it has the wrong signature. Declaring FUNCTION with a different
+ signature in C is a compilation error, so this macro must use the
+ same type as any existing declaration so that programs that avoid
+ the problematic FUNCTION do not fail to compile merely because they
+ included a header that poisoned the function. But this implies that
+ _GL_WARN_ON_USE is only safe to use if FUNCTION is known to already
+ have a declaration. Use of this macro implies that there must not
+ be any other macro hiding the declaration of FUNCTION; but
+ undefining FUNCTION first is part of the poisoning process anyway
+ (although for symbols that are provided only via a macro, the result
+ is a compilation error rather than a warning containing
+ "literal string"). Also note that in C++, it is only safe to use if
+ FUNCTION has no overloads.
For an example, it is possible to poison 'getline' by:
- adding a call to gl_WARN_ON_USE_PREPARE([[#include <stdio.h>]],
(less common usage, like &environ, will cause a compilation error
rather than issue the nice warning, but the end result of informing
the developer about their portability problem is still achieved):
- #if HAVE_RAW_DECL_ENVIRON
- static char ***rpl_environ (void) { return &environ; }
- _GL_WARN_ON_USE (rpl_environ, "environ is not always properly declared");
- # undef environ
- # define environ (*rpl_environ ())
- #endif
+ #if HAVE_RAW_DECL_ENVIRON
+ static char ***
+ rpl_environ (void) { return &environ; }
+ _GL_WARN_ON_USE (rpl_environ, "environ is not always properly declared");
+ # undef environ
+ # define environ (*rpl_environ ())
+ #endif
+ or better (avoiding contradictory use of 'static' and 'extern'):
+ #if HAVE_RAW_DECL_ENVIRON
+ static char ***
+ _GL_WARN_ON_USE_ATTRIBUTE ("environ is not always properly declared")
+ rpl_environ (void) { return &environ; }
+ # undef environ
+ # define environ (*rpl_environ ())
+ #endif
*/
#ifndef _GL_WARN_ON_USE
/* A compiler attribute is available in gcc versions 4.3.0 and later. */
# define _GL_WARN_ON_USE(function, message) \
extern __typeof__ (function) function __attribute__ ((__warning__ (message)))
+# define _GL_WARN_ON_USE_ATTRIBUTE(message) \
+ __attribute__ ((__warning__ (message)))
# elif __GNUC__ >= 3 && GNULIB_STRICT_CHECKING
/* Verify the existence of the function. */
# define _GL_WARN_ON_USE(function, message) \
extern __typeof__ (function) function
+# define _GL_WARN_ON_USE_ATTRIBUTE(message)
# else /* Unsupported. */
# define _GL_WARN_ON_USE(function, message) \
_GL_WARN_EXTERN_C int _gl_warn_on_use
+# define _GL_WARN_ON_USE_ATTRIBUTE(message)
# endif
#endif
if isdigit is mistakenly implemented via a static inline function,
a program containing an extern inline function that calls isdigit
may not work since the C standard prohibits extern inline functions
- from calling static functions. This bug is known to occur on:
+ from calling static functions (ISO C 99 section 6.7.4.(3).
+ This bug is known to occur on:
OS X 10.8 and earlier; see:
https://lists.gnu.org/r/bug-gnulib/2012-12/msg00023.html
OS X 10.9 has a macro __header_inline indicating the bug is fixed for C and
for clang but remains for g++; see <https://trac.macports.org/ticket/41033>.
- Assume DragonFly and FreeBSD will be similar. */
+ Assume DragonFly and FreeBSD will be similar.
+
+ GCC 4.3 and above with -std=c99 or -std=gnu99 implements ISO C99
+ inline semantics, unless -fgnu89-inline is used. It defines a macro
+ __GNUC_STDC_INLINE__ to indicate this situation or a macro
+ __GNUC_GNU_INLINE__ to indicate the opposite situation.
+ GCC 4.2 with -std=c99 or -std=gnu99 implements the GNU C inline
+ semantics but warns, unless -fgnu89-inline is used:
+ warning: C99 inline functions are not supported; using GNU89
+ warning: to disable this warning use -fgnu89-inline or the gnu_inline function attribute
+ It defines a macro __GNUC_GNU_INLINE__ to indicate this situation.
+ */
#if (((defined __APPLE__ && defined __MACH__) \
|| defined __DragonFly__ || defined __FreeBSD__) \
&& (defined __header_inline \
projects / emacs.git / commitdiff