- 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.