* build-aux/gendocs.sh (version):
* doc/gendocs_template:
* doc/gendocs_template_min:
* doc/gnulib.texi:
* lib/version-etc.c (COPYRIGHT_YEAR):
Update copyright dates by hand in templates and the like.
* all files: Run 'make update-copyright'.
* build-aux/gendocs.sh (version):
* doc/gendocs_template:
* doc/gendocs_template_min:
* doc/gnulib.texi:
* lib/version-etc.c (COPYRIGHT_YEAR):
Update copyright dates by hand in templates and the like.
* all files: Run 'make update-copyright'.
Gnulib intentionally does not have a gets module, and now that C11
and glibc have dropped it, we should be more proactive about warning
any user on a platform that still has a declaration of this dangerous
interface.
* m4/stdio_h.m4 (gl_STDIO_H, gl_STDIO_H_DEFAULTS): Drop gets
support.
* modules/stdio (Makefile.am): Likewise.
* lib/stdio-read.c (gets): Likewise.
* tests/test-stdio-c++.cc: Likewise.
* m4/warn-on-use.m4 (gl_WARN_ON_USE_PREPARE): Fix comment.
* lib/stdio.in.h (gets): Make warning occur in more places.
* doc/posix-functions/gets.texi (gets): Update documentation.
Reported by Christer Solskogen.
Signed-off-by: Eric Blake <eblake@redhat.com>
Before autoconf documented the AS_VAR_* interfaces, it used to
require the user to pre-expand the pushed macro name. Newer
autoconf can see through macros, but this is one case where
breaking the rule of thumb and underquoting does not hurt.
* m4/warn-on-use.m4 (gl_WARN_ON_USE_PREPARE): Accomodate older
AS_VAR semantics of autoconf 2.60.
Reported by Bruno Haible.
Signed-off-by: Eric Blake <eblake@redhat.com>
The goal of GNULIB_POSIXCHECK is to allow a developer on a reasonably
portable system to detect instances where they may have succeeded
because their system is up-to-date, but where compilation would fail
or create a misbehaving application on some other system due to some
portability problem, all without requiring that the developer have
access to other machines. In other words, we want to poison all
interfaces that have a gnulib replacement if the corresponding gnulib
module is not in use. For macros, the solution is undefining the
macro; unfortunately this causes compilation error without many
details as to why, but it is better than nothing. For functions, the
solution is to cause a warning if the function is used.
Previously, the link-warning could poison functions, but only on glibc
systems and with gcc. This module introduces _GL_WARN_ON_USE as a way
of poisoning functions for a few more systems.
Using the gcc __warning__ attribute (added in 4.3.0, early 2008)
rather than using link-warning.h is favorable because:
1) Provides a warning immediately at compile-time. The user does not
have to wait until he links a program.
2) Less use of C macros. Less risk of collision.
3) It's available on more platforms. Depends only on GCC.
4) The formatting of the message is nicer.
There is a minor regression: the gcc attribute is currently not as
powerful as a link warning at detecting uses via function pointers:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42384
However, that style of coding is less frequent.
* modules/warn-on-use: New file.
* build-aux/warn-on-use.h: Likewise.
* m4/warn-on-use.m4: Likewise.
* MODULES.html.sh (Support for building): Mention it.
Signed-off-by: Eric Blake <ebb9@byu.net>
