Commit ba8eb994 authored by Paul Eggert's avatar Paul Eggert

Update from gnulib

This incorporates:
2018-08-05 Fix link error regarding 'rpl_environ'
* build-aux/config.guess, lib/unistd.in.h, lib/warn-on-use.h:
* m4/extern-inline.m4: Copy from Gnulib.
parent 56683b13
......@@ -2,7 +2,7 @@
# Attempt to guess a canonical system name.
# Copyright 1992-2018 Free Software Foundation, Inc.
timestamp='2018-07-18'
timestamp='2018-08-02'
# This file is free software; you can redistribute it and/or modify it
# under the terms of the GNU General Public License as published by
......@@ -126,7 +126,7 @@ set_cc_for_build() {
# This is needed to find uname on a Pyramid OSx when run in the BSD universe.
# (ghazi@noc.rutgers.edu 1994-08-24)
if (test -f /.attbin/uname) >/dev/null 2>&1 ; then
if test -f /.attbin/uname ; then
PATH=$PATH:/.attbin ; export PATH
fi
......
......@@ -432,12 +432,12 @@ extern char **environ;
#elif defined GNULIB_POSIXCHECK
# if HAVE_RAW_DECL_ENVIRON
_GL_UNISTD_INLINE char ***
_GL_WARN_ON_USE_ATTRIBUTE ("environ is unportable - "
"use gnulib module environ for portability")
rpl_environ (void)
{
return &environ;
}
_GL_WARN_ON_USE (rpl_environ, "environ is unportable - "
"use gnulib module environ for portability");
# undef environ
# define environ (*rpl_environ ())
# endif
......
......@@ -20,23 +20,32 @@
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>]],
......@@ -54,12 +63,21 @@
(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
......@@ -67,13 +85,17 @@
/* 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
......
......@@ -25,7 +25,8 @@ AC_DEFUN([gl_EXTERN_INLINE],
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
......@@ -38,7 +39,18 @@ AC_DEFUN([gl_EXTERN_INLINE],
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 \
......
Markdown is supported
0% or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment