Re: fdl-1.3
A symlink?! This can only cause problems: - When 'git' is run on a Windows system (not Cygwin), AFAIK there are no symlinks. In which case, git treats the file as a single line text, whose contents would correspond to the symlink, but the contents of the git tree make it obvious (via the different object mode) that it is a link. - When 'git' is run on Linux on a vfat file system, there are - no symlinks. Ditto. git can already work around such deficient file systems when it comes to versioning the file, and hopefully no one is crazy enough to actually try developing git on such a file system. But makeinfo, copy and others do not work around such deficient file systems, and one cannot expect every tool to do so. - When you use 'tar' with option 'h' to copy the directory, the copy will be different from the original: it will have the symlink replaced by its target's contents. Which is perfectly fine - the copy in gnulib is for reference, and whether it is a symlink or a copy shouldn't matter. It just made my life as autoconf maintainer easier to be able to add a line to cfg.mk that does 'cp gnulib/doc/fdl.texi autoconf/doc/', http://git.savannah.gnu.org/gitweb/?p=autoconf.git;a=commitdiff;h=5bf2204#patch2 That will not work if you do it on a vfat filesystem, all you will get is a single line text file; which will produce the wrong info manual. It will also not help if you wish to use fdl.texi directly on a vfat file system. The problem is not git handling things like this, but other programs. Please, can't you make fdl.texi a regular file? Either with contents @include fdl-1.3.texi or as a copy of fdl-1.3.texi? This is a nice and simple solution.
Re: getaddrinfo, netdb, canon-host
Bruno Haible [EMAIL PROTECTED] writes: Simon Josefsson wrote on 2008-10-20: * lib/getaddrinfo.h: Remove file. * modules/getaddrinfo: Reflect move from getaddrinfo.h to netdb.h. * m4/getaddrinfo.m4: Call gl_HEADER_NETDB. Don't check for netdb.h. * lib/netdb.in.h: Add declarations from getaddrinfo.h. In order to keep gnulib-generated header files as independent from config.h as possible, I'm applying this. Simon, I hope it's right? Thanks for catching that! /Simon
Re: sockets.h comment
Bruno Haible [EMAIL PROTECTED] writes: Hi Simon, Naive as I was, I wanted to use the 'sockets' module, specifying the minimum possible requirement for winsock. Bummer! This version is not supported any more on Windows XP. I propose to put a comment about it. OK? Yes, please do. Maybe also add a link to http://msdn.microsoft.com/en-us/library/ms742213(VS.85).aspx which contains much additional information? It says 1.0 should work, but I've also noticed that it doesn't, and generally use 1.1 or 2.1 instead. This seems like a common problem with MSDN, e.g., the documentation says getaddrinfo should be available in all Windows versions, but it doesn't exist on Windows 2000 for example (IIRC). /Simon 2008-11-10 Bruno Haible [EMAIL PROTECTED] * lib/sockets.h: Add a comment. --- lib/sockets.h.orig2008-11-11 01:25:47.0 +0100 +++ lib/sockets.h 2008-11-11 01:25:45.0 +0100 @@ -20,9 +20,9 @@ #ifndef SOCKETS_H # define SOCKETS_H 1 -#define SOCKETS_1_0 0x100 +#define SOCKETS_1_0 0x100 /* don't use - does not work on Windows XP */ #define SOCKETS_1_1 0x101 -#define SOCKETS_2_0 0x200 +#define SOCKETS_2_0 0x200 /* don't use - does not work on Windows XP */ #define SOCKETS_2_1 0x201 #define SOCKETS_2_2 0x202
Re: test-select-out failures
Bruno Haible [EMAIL PROTECTED] writes:
Simon Josefsson wrote:
The failing test is the first pipe test:
( { echo abc; ./test-select-fd w 1; } | { sleep 1; cat; } ) /dev/null 2
t-select-out.tmp
test `cat t-select-out.tmp` = 0 || echo exit
Those two commands prints 'exit' here. The other tests, including the
second pipe test works fine.
OK, it was probably unwise to rely on specific contents of stderr in a
test. (When I add set -x as second line of the test, for debugging,
it also fails due to extraneous output to stderr.)
This should improve things:
It doesn't solve the problem on my system, though:
[EMAIL PROTECTED]:~/src/gnulib/testdir1013/build/gltests master$ bash -x
../../gltests/test-select-out.sh
+ tmpfiles=
+ trap 'rm -fr $tmpfiles' 1 2 3 15
+ tmpfiles=' t-select-out.out t-select-out.tmp'
+ rm -f t-select-out.tmp
+ ./test-select-fd w 1 t-select-out.tmp
++ cat t-select-out.tmp
+ test 1 = 1
+ rm -f t-select-out.tmp
+ echo abc
+ ./test-select-fd w 1 t-select-out.tmp
+ sleep 1
+ cat
++ cat t-select-out.tmp
+ test 1 = 0
+ exit 1
[EMAIL PROTECTED]:~/src/gnulib/testdir1013/build/gltests master$ echo $?
1
[EMAIL PROTECTED]:~/src/gnulib/testdir1013/build/gltests master$
[EMAIL PROTECTED]:~/src/gnulib/testdir1013/build/gltests master$ ( { echo abc;
./test-select-fd${EXEEXT} w 1 t-select-out.tmp; } | { sleep 1; cat; } )
/dev/null
[EMAIL PROTECTED]:~/src/gnulib/testdir1013/build/gltests master$ cat
t-select-out.tmp
1
[EMAIL PROTECTED]:~/src/gnulib/testdir1013/build/gltests master$
Ideas?
It seems to happen on my build machine as well:
http://autobuild.josefsson.org/gnulib/log-20080357663564000.txt
It is also a x86 debian testing machine, so no surprise.
Thanks,
/Simon
Re: warning: module to simplify adding compiler warnings
Bruno Haible [EMAIL PROTECTED] writes: Simon Josefsson wrote: It allows me to add to configure.ac this: gl_WARN_ADD([-Wall]) gl_WARN_ADD([-Wpointer-arith]) gl_WARN_ADD([-Wstrict-prototypes]) gl_WARN_ADD([-Wno-pointer-sign]) Will $WARN_CFLAGS be used before or after $CFLAGS? I.e. can the user disable these warning flags or not? That's up to each maintainer, WARN_CFLAGS isn't added to CFLAGS automatically. I'm using this in libtasn1's src/Makefile.am: AM_CFLAGS = $(WARN_CFLAGS) AM_CPPFLAGS = -I$(top_srcdir)/lib -I$(top_srcdir)/gl -I$(top_builddir)/gl ... This makes it possible to gradually fix code, just add $(WARN_CFLAGS) in those directories that you've solved all warnings for. (For example, in some projects the gnulib directory triggers warning that I would want to fix elsewhere in the project, but I don't want the build to fail because of the gnulib code.) gl_WARN_ADD([-Werror]) This is a bad idea. It will cause gratuitous frustration for users on platforms that you haven't tested. Remember that many warnings do not indicate something really wrong with the program, only the _possibility_ that something is wrong. The user will then need two attempts to build a package, instead of only one. Or he will choose to build with a proprietary compiler rather than with gcc. IMO this is just the opposite of portability. I agree, however, -Werror is useful during 'make distcheck'. I'm going to remove the above line from configure.ac and pass the flag to configure in cfg.mk instead. It would be better to make the macro bail out at autoconf time if someone attempts to put gl_WARN_ADD([-Werror]) into his configure.ac file. This is too much, I think, and would break an IMHO realistic use-case of putting -Werror in WARN_CFLAGS during make distcheck. I've pushed the module. /Simon
Re: fdl-1.3
Eric Blake wrote: It just made my life as autoconf maintainer easier to be able to add a line to cfg.mk that does 'cp gnulib/doc/fdl.texi autoconf/doc/', This will work also when fdl.texi is simply a copy of fdl-1.3.texi. Bruno
Re: warning: module to simplify adding compiler warnings
Paolo Bonzini [EMAIL PROTECTED] writes: Simon Josefsson wrote: Paolo Bonzini [EMAIL PROTECTED] writes: But gl_WARN_INIT should also accept a VARIABLE argument, then? Or better, make gl_WARN_INIT automatic upon the first use of gl_WARN_ADD with the given VARIABLE? You have a point; however, gl_WARN_INIT would then need a second argument for the description too, and then the user can directly use AC_ARG_VAR. For that reason, I'd be in favor of requiring a gl_WARN_INIT for each variable used. That might avoid strange effects due to typos too. I'm not sure all users want to use AC_ARG_VAR for every warning variable. Good point. Still, making it possible for users to use the same idiom to add all warning flags might be useful? That would allow something like: gl_WARN_INIT(WARN_CFLAGS, [C Compiler warning flags]) gl_WARN_INIT(WARN_FOO_CFLAGS, [Extra C Compiler warning flags for foo]) gl_WARN_ADD(-Wbar) gl_WARN_ADD(-Wfoo, WARN_FOO_CFLAGS) gl_WARN_ADD(-Wapa, WARN_OTHER_INTERNAL_CFLAGS) Maybe presence of a comment should decide whether to use AC_ARG_VAR on it? E.g. the first block would then be: gl_WARN_INIT(WARN_CFLAGS, [C Compiler warning flags]) gl_WARN_INIT(WARN_FOO_CFLAGS, [Extra C Compiler warning flags for foo]) gl_WARN_INIT(WARN_OTHER_INTERNAL_CFLAGS) The gl_WARN_INIT code would invoke AC_ARG_VAR on the first and second variable, but not the last. /Simon
Re: warning: module to simplify adding compiler warnings
gl_WARN_INIT(WARN_CFLAGS, [C Compiler warning flags]) gl_WARN_INIT(WARN_FOO_CFLAGS, [Extra C Compiler warning flags for foo]) gl_WARN_INIT(WARN_OTHER_INTERNAL_CFLAGS) The gl_WARN_INIT code would invoke AC_ARG_VAR on the first and second variable, but not the last. But what would the third invocation do? As it is now, it would be a no-op, and the first two would be synonyms for AC_ARG_VAR. Paolo
Re: warning: module to simplify adding compiler warnings
Paolo Bonzini [EMAIL PROTECTED] writes: gl_WARN_INIT(WARN_CFLAGS, [C Compiler warning flags]) gl_WARN_INIT(WARN_FOO_CFLAGS, [Extra C Compiler warning flags for foo]) gl_WARN_INIT(WARN_OTHER_INTERNAL_CFLAGS) The gl_WARN_INIT code would invoke AC_ARG_VAR on the first and second variable, but not the last. But what would the third invocation do? As it is now, it would be a no-op, and the first two would be synonyms for AC_ARG_VAR. All of them would run AC_SUBST. /Simon
Re: warning: module to simplify adding compiler warnings
Simon Josefsson wrote: Paolo Bonzini [EMAIL PROTECTED] writes: gl_WARN_INIT(WARN_CFLAGS, [C Compiler warning flags]) gl_WARN_INIT(WARN_FOO_CFLAGS, [Extra C Compiler warning flags for foo]) gl_WARN_INIT(WARN_OTHER_INTERNAL_CFLAGS) The gl_WARN_INIT code would invoke AC_ARG_VAR on the first and second variable, but not the last. But what would the third invocation do? As it is now, it would be a no-op, and the first two would be synonyms for AC_ARG_VAR. All of them would run AC_SUBST. It is already done in gl_WARN_ADD though. Paolo
Re: warning: module to simplify adding compiler warnings
An AC_SUBST([WARN_CFLAGS]) is missing somewhere. Why should the user have to do it himself? We know that WARN_CFLAGS is meant to be used in Makefile.ams. Bruno
Re: warning: module to simplify adding compiler warnings
Paolo Bonzini [EMAIL PROTECTED] writes: Simon Josefsson wrote: Paolo Bonzini [EMAIL PROTECTED] writes: gl_WARN_INIT(WARN_CFLAGS, [C Compiler warning flags]) gl_WARN_INIT(WARN_FOO_CFLAGS, [Extra C Compiler warning flags for foo]) gl_WARN_INIT(WARN_OTHER_INTERNAL_CFLAGS) The gl_WARN_INIT code would invoke AC_ARG_VAR on the first and second variable, but not the last. But what would the third invocation do? As it is now, it would be a no-op, and the first two would be synonyms for AC_ARG_VAR. All of them would run AC_SUBST. It is already done in gl_WARN_ADD though. Ah. Hm. Then I see no point in my suggestion, please disregard it. /Simon
Re: warning: module to simplify adding compiler warnings
+# gl_WARN_ADD([parameter]) adds parameter to WARN_CFLAGS if compiler +# supports it. For example, use gl_WARN_ADD([-Werror]). +AC_DEFUN([gl_WARN_ADD], +[ + pushdef([param],[translit([$1],[ABCDEFGHIJKLMNOPQRSTUVWXYZ./-], + [abcdefghijklmnopqrstuvwxyz___])]) There are m4sh macros AS_VAR_SET, AS_VAR_PUSH, AS_VAR_POP, AS_VAR_IF that help doing this and support things like for i in no-foo bar no-baz; do gl_WARN_ADD([-W$i]) done I can do the change, or you can do it; as you prefer. In any case if you pushdef you'd better popdef too. :-) Paolo
Re: fdl-1.3
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 According to Bruno Haible on 11/11/2008 4:25 AM: Eric Blake wrote: It just made my life as autoconf maintainer easier to be able to add a line to cfg.mk that does 'cp gnulib/doc/fdl.texi autoconf/doc/', This will work also when fdl.texi is simply a copy of fdl-1.3.texi. I went with the full copy, then. - -- Don't work too hard, make some time for fun as well! Eric Blake [EMAIL PROTECTED] -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (Cygwin) Comment: Public key at home.comcast.net/~ericblake/eblake.gpg Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkkZgtQACgkQ84KuGfSFAYBf+ACePcfGHQXJ31EBVKwu4Sovpst3 z4sAoIxovX09Dxqwskc98N6rhfgOhUMQ =LDNb -END PGP SIGNATURE-
glibc's snprintf bug causes printf(1) failure with MALLOC_PERTURB_ != 0
Using printf from GNU coreutils newer than 6.9, I get this
on rawhide (glibc-2.8.90-16) which looks wrong, but isn't serious:
(it shouldn't allocate a 30MB buffer just to fill it with '0's and
print it)
$ (ulimit -v 2; env MALLOC_PERTURB_=1 printf '%.3000f' 0)
printf: write error
But, on Debian unstable (libc6 2.7-16) there's a bigger problem:
$ (ulimit -v 2; env MALLOC_PERTURB_=1 printf '%.3000f' 0)
zsh: segmentation fault
$ dmesg|tail -1
[75236.189009] printf[26494]: segfault at 0 ip 7f9e90598520 sp \
7fff98a87c28 error 6 in libc-2.7.so[7f9e9051c000+14a000]
The latter failure is due to a glibc snprintf bug discussed in:
http://bugs.debian.org/481543
http://bugzilla.redhat.com/470831 (RHEL5)
If you're into development and can deal with occasional
tool/infrastructure misbehavior, I strongly recommend that you
set the MALLOC_PERTURB_ envvar -- if you do, use a value in 1..255.
I use the following:
# http://udrepper.livejournal.com/11429.html
export MALLOC_PERTURB_=$(($RANDOM % 255 + 1))
It would be good for gnulib to detect the bug and to use
the replacement snprintf on losing systems.
=
For reference, here's a C-only reproducer based on what
I wrote in the bug reports:
cat EOF k.c
#include stdio.h
#include stdlib.h
int
main(int argc, char **argv)
{
char buf[200];
char *fmt = argv[1];
if (argc 2)
abort ();
int n = snprintf (buf, sizeof buf, fmt, 1);
return 0*n;
}
EOF
I chose to eliminate the shared-libraries:
gcc -static -W -Wall k.c
Then run it like this:
env -i -- zsh -f -c \
'ulimit -v 5000; MALLOC_PERTURB_=9 ./a.out %$[5*2**20]d' || dmesg|tail -1
This example also demonstrates a problem with glibc
(whether it's a standards violation or merely a QoI issue is debatable)
IMHO, such a use of snprintf should not fail with ENOMEM, given
any but the most pathological floating point input arguments.
And with a format directives like s d i u o, etc., it should *never* fail.
Of course, if you want to use %$[5*2**20]s on the command
line, you'll have to change the `1' argument above to a string, e.g., `1'.
FYI, the libc in freebsd 6.1 and newer has no problem with the above
snprintf usage. And coreutils' printf command prints the 30 million 0's
without allocating an inordinate amount of storage.
Re: warning: module to simplify adding compiler warnings
Paolo Bonzini [EMAIL PROTECTED] writes: I can do the change, or you can do it; as you prefer. In any case if you pushdef you'd better popdef too. :-) Please apply your change and I'll test whether it works for me. Here it is. I also added a second argument to choose the destination variable instead of hardcoding it to WARN_CFLAGS. Great idea, thanks. By the way, I just noticed an (unused?) warning.m4 file. Ok to delete it? It added warnings to CFLAGS, so I couldn't use it. I think it is better for users of warning.m4 used warnings.m4 instead. /Simon
Re: warning: module to simplify adding compiler warnings
* Simon Josefsson wrote on Tue, Nov 11, 2008 at 02:23:14PM CET: Paolo Bonzini [EMAIL PROTECTED] writes: But gl_WARN_INIT should also accept a VARIABLE argument, then? Or better, make gl_WARN_INIT automatic upon the first use of gl_WARN_ADD with the given VARIABLE? You have a point; however, gl_WARN_INIT would then need a second argument for the description too, and then the user can directly use AC_ARG_VAR. FWIW, I wouldn't use AC_ARG_VAR for gl_WARN_INIT. There is no reason that configure should exit when warning flags are changed from cache contents: the very point of this patch is that they do not influence configure tests. No? Cheers, Ralf
Re: warning: module to simplify adding compiler warnings
Paolo Bonzini wrote:
By the way, I just noticed an (unused?) warning.m4 file. Ok to delete it?
As far as I understood the modivation for Simon's new module, the old
warning.m4 file does not match these requirements, therefore yes it is OK
to delete it; only Bison uses it.
Here's what I understood:
-
The @code{warnings} module allows to regularly build a package with more
GCC warnings than the default warnings emitted by GCC.
It provides the following functionality:
@itemize @bullet
@item
You can select some warning options, such as @samp{-Wall}, to be enabled
whenever building with a GCC version that supports these options. The
user can choose to override these warning options by providing the
opposite options in the @code{CFLAGS} variable at configuration time.
@item
You can make these warnings apply to selected directories only. In
projects where subprojects are maintained by different people, or where
parts of the source code are imported from external sources -- for example
from gnulib --, it is useful to apply different warning options to
different directories.
@item
It allows to use @samp{-Werror} at @samp{make distcheck} time, to verify
that on the maintainer's system, no warnings remain. (Note that use of
@samp{-Werror} in @code{CFLAGS} does not work in general, because it may
break autoconfiguration.)
@end itemize
To use this module, you need the following:
@enumerate
@item
In @file{configure.ac}, use for example
@smallexample
gl_WARN_ADD([-Wall], [WARN_CFLAGS])
gl_WARN_ADD([-Wpointer-arith], [WARN_CFLAGS])
@end smallexample
@item
In the directories which shall use @code{WARN_CFLAGS}, use it in the
definition of @code{AM_CFLAGS}, like this:
@smallexample
AM_CFLAGS = $(WARN_CFLAGS)
@end smallexample
Note that the @code{AM_CFLAGS} is used in combination with @code{CFLAGS}
and before @code{CFLAGS} in build rules emitted by Automake. This allows
the user to provide @code{CFLAGS} that override the @code{WARN_CFLAGS}.
@end enumerate
Note that it is a bad idea to use @samp{gl_WARN_ADD([-Werror])}. The
warnings emitted by GCC depend, to some extent, on the contents of the
system header files, on the size and signedness of built-in types, etc.
Use of @samp{-Werror} would cause frustration to all users on platforms
that the maintainer has not tested before the release. It is better if
maintainers use @samp{-Werror} only for themselves (for example, during
@samp{make distcheck}, as mentioned above).
-
Simon, maybe you can add a piece of text like this as documentation?
Bruno
Re: warning: module to simplify adding compiler warnings
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 According to Paolo Bonzini on 11/11/2008 5:52 AM: AS_LITERAL_IF is not documented in autoconf 2.63. Is there a documented replacement? No, but it has been forever in M4sh. I'll prepare a documentation patch. It's already been documented, as part of documenting AS_VAR (the documentation is only in autoconf.git, but the macro has indeed been around for a long time). Also, if only one argument is given, won't this do an AC_SUBST([]) ? Yes. And I thought it was a no-op (that's why I AC_SUBSTed WARN_CFLAGS separately), but it gives an error. Should AS_LITERAL_IF be taught to treat the empty argument as non-literal? - -- Don't work too hard, make some time for fun as well! Eric Blake [EMAIL PROTECTED] -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (Cygwin) Comment: Public key at home.comcast.net/~ericblake/eblake.gpg Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkkZgdYACgkQ84KuGfSFAYDoDQCgh3Q0CHD8Zk9WnbQH/Zacn/zT i+AAn2zfC5h2f27Q7u3OrQzCpQkHCfJn =7zv6 -END PGP SIGNATURE-
Re: warning: module to simplify adding compiler warnings
Paolo Bonzini [EMAIL PROTECTED] writes: But gl_WARN_INIT should also accept a VARIABLE argument, then? Or better, make gl_WARN_INIT automatic upon the first use of gl_WARN_ADD with the given VARIABLE? You have a point; however, gl_WARN_INIT would then need a second argument for the description too, and then the user can directly use AC_ARG_VAR. For that reason, I'd be in favor of requiring a gl_WARN_INIT for each variable used. That might avoid strange effects due to typos too. /Simon
Re: warning: module to simplify adding compiler warnings
Bruno Haible wrote: Paolo Bonzini wrote: @@ -47,4 +47,5 @@ gl_AS_VAR_IF([gl_Warn], [yes], [gl_AS_VAR_APPEND([gl_Flags], [ $1])]) AS_VAR_POPDEF([gl_Flags])dnl AS_VAR_POPDEF([gl_Warn])dnl +AS_LITERAL_IF([$2], [AC_SUBST([$2])], [])dnl AS_LITERAL_IF is not documented in autoconf 2.63. Is there a documented replacement? No, but it has been forever in M4sh. I'll prepare a documentation patch. Also, if only one argument is given, won't this do an AC_SUBST([]) ? Yes. And I thought it was a no-op (that's why I AC_SUBSTed WARN_CFLAGS separately), but it gives an error. diff --git a/m4/warnings.m4 b/m4/warnings.m4 index ca9bf5e..71a8e56 100644 --- a/m4/warnings.m4 +++ b/m4/warnings.m4 @@ -47,5 +47,5 @@ gl_AS_VAR_IF([gl_Warn], [yes], [gl_AS_VAR_APPEND([gl_Flags], [ $1])]) AS_VAR_POPDEF([gl_Flags])dnl AS_VAR_POPDEF([gl_Warn])dnl -AS_LITERAL_IF([$2], [AC_SUBST([$2])], [])dnl +m4_ifval([$2], [AS_LITERAL_IF([$2], [AC_SUBST([$2])], [])])dnl ]) Paolo
Re: warning: module to simplify adding compiler warnings
Bruno Haible wrote: An AC_SUBST([WARN_CFLAGS]) is missing somewhere. Why should the user have to do it himself? We know that WARN_CFLAGS is meant to be used in Makefile.ams. I'm committing this: 2008-11-11 Paolo Bonzini [EMAIL PROTECTED] * m4/warnings.m4 (gl_WARN_INIT): Substitute WARN_CFLAGS. (gl_WARN_ADD): Substitute $2 if literal. diff --git a/m4/warnings.m4 b/m4/warnings.m4 index 634b183..ca9bf5e 100644 --- a/m4/warnings.m4 +++ b/m4/warnings.m4 @@ -9,8 +9,8 @@ dnl From Simon Josefsson # gl_WARN_INIT # Initializes WARN_CFLAGS variable. AC_DEFUN([gl_WARN_INIT], -[ - AC_ARG_VAR(WARN_CFLAGS, [C compiler warning flags]) +[AC_SUBST([WARN_CFLAGS])dnl +AC_ARG_VAR([WARN_CFLAGS], [C compiler warning flags]) ]) # gl_AS_VAR_IF(VAR, VALUE, [IF-MATCH], [IF-NOT-MATCH]) @@ -47,4 +47,5 @@ gl_AS_VAR_IF([gl_Warn], [yes], [gl_AS_VAR_APPEND([gl_Flags], [ $1])]) AS_VAR_POPDEF([gl_Flags])dnl AS_VAR_POPDEF([gl_Warn])dnl +AS_LITERAL_IF([$2], [AC_SUBST([$2])], [])dnl ])
Re: warning: module to simplify adding compiler warnings
Also, if only one argument is given, won't this do an AC_SUBST([]) ? Yes. And I thought it was a no-op (that's why I AC_SUBSTed WARN_CFLAGS separately), but it gives an error. Should AS_LITERAL_IF be taught to treat the empty argument as non-literal? No, absolutely. That's the purpose of things such as AS_IDENTIFIER_IF, which is what AC_SUBST uses. I cannot think of a use case for AS_LITERAL_IF on an empty argument, but that's actually because I cannot think right now of a use case for macros accepting empty arguments in general. Paolo
Re: warning: module to simplify adding compiler warnings
Bruno Haible wrote: Paolo Bonzini wrote: By the way, I just noticed an (unused?) warning.m4 file. Ok to delete it? As far as I understood the modivation for Simon's new module, the old warning.m4 file does not match these requirements, therefore yes it is OK to delete it; only Bison uses it. I removed it and updated Bison to use the new warnings.m4 file. diff --git a/NEWS b/NEWS index 0602705..45c23ce 100644 --- a/NEWS +++ b/NEWS @@ -6,6 +6,9 @@ User visible incompatible changes DateModulesChanges +2008-11-11 warnings This module subsumes the file m4/warning.m4 + which was removed. + 2008-10-20 lstat The include file is changed from lstat.h to sys/stat.h.
Re: warning: module to simplify adding compiler warnings
Paolo Bonzini wrote: I also added a second argument to choose the destination variable instead of hardcoding it to WARN_CFLAGS. This is good: it supports packages which are maintained by several people, with different coding guidelines in different directories. But gl_WARN_INIT should also accept a VARIABLE argument, then? Or better, make gl_WARN_INIT automatic upon the first use of gl_WARN_ADD with the given VARIABLE? Bruno
Re: warning: module to simplify adding compiler warnings
Simon Josefsson wrote:
Paolo Bonzini [EMAIL PROTECTED] writes:
But gl_WARN_INIT should also accept a VARIABLE argument, then? Or better,
make gl_WARN_INIT automatic upon the first use of gl_WARN_ADD with the
given VARIABLE?
You have a point; however, gl_WARN_INIT would then need a second
argument for the description too, and then the user can directly use
AC_ARG_VAR.
For that reason, I'd be in favor of requiring a gl_WARN_INIT for each
variable used. That might avoid strange effects due to typos too.
I'm not sure all users want to use AC_ARG_VAR for every warning
variable. Actually, I don't see the point of using AC_ARG_VAR unless
the user can override the variable. Something like
in gl_WARN_INIT:
if test x${WARN_CFLAGS+set} = xset; then
gl_overridden_WARN_CFLAGS=yes
else
gl_overridden_WARN_CFLAGS=no
fi
in gl_WARN_ADD:
do not add -W$1 to variable $2 if gl_overridden_$2=yes
Paolo
Re: warning: module to simplify adding compiler warnings
Paolo Bonzini [EMAIL PROTECTED] writes: +# gl_WARN_ADD([parameter]) adds parameter to WARN_CFLAGS if compiler +# supports it. For example, use gl_WARN_ADD([-Werror]). +AC_DEFUN([gl_WARN_ADD], +[ + pushdef([param],[translit([$1],[ABCDEFGHIJKLMNOPQRSTUVWXYZ./-], + [abcdefghijklmnopqrstuvwxyz___])]) There are m4sh macros AS_VAR_SET, AS_VAR_PUSH, AS_VAR_POP, AS_VAR_IF that help doing this and support things like for i in no-foo bar no-baz; do gl_WARN_ADD([-W$i]) done Ah, seems good! I can do the change, or you can do it; as you prefer. In any case if you pushdef you'd better popdef too. :-) Please apply your change and I'll test whether it works for me. /Simon
Re: warning: module to simplify adding compiler warnings
Paolo Bonzini wrote: @@ -47,4 +47,5 @@ gl_AS_VAR_IF([gl_Warn], [yes], [gl_AS_VAR_APPEND([gl_Flags], [ $1])]) AS_VAR_POPDEF([gl_Flags])dnl AS_VAR_POPDEF([gl_Warn])dnl +AS_LITERAL_IF([$2], [AC_SUBST([$2])], [])dnl AS_LITERAL_IF is not documented in autoconf 2.63. Is there a documented replacement? Also, if only one argument is given, won't this do an AC_SUBST([]) ? Bruno
Re: warning: module to simplify adding compiler warnings
* Simon Josefsson wrote on Tue, Nov 11, 2008 at 10:32:42AM CET: IMO this is just the opposite of portability. I agree, however, -Werror is useful during 'make distcheck'. I'm going to remove the above line from configure.ac and pass the flag to configure in cfg.mk instead. Why not just set DISTCHECK_CONFIGURE_FLAGS in cfg.mk instead? Then you can just omit this whole module. Cheers, Ralf
Re: warning: module to simplify adding compiler warnings
I can do the change, or you can do it; as you prefer. In any case if
you pushdef you'd better popdef too. :-)
Please apply your change and I'll test whether it works for me.
Here it is. I also added a second argument to choose the destination
variable instead of hardcoding it to WARN_CFLAGS.
Unfortunately some AS_* macros have to be redefined for backwards
compatibility. If it was not for that, the rewrite would have the same
number of lines as your version. :-)
By the way, I just noticed an (unused?) warning.m4 file. Ok to delete it?
Paolo
diff --git a/m4/warnings.m4 b/m4/warnings.m4
index 594ff97..634b183 100644
--- a/m4/warnings.m4
+++ b/m4/warnings.m4
@@ -13,22 +13,38 @@ AC_DEFUN([gl_WARN_INIT],
AC_ARG_VAR(WARN_CFLAGS, [C compiler warning flags])
])
-# gl_WARN_ADD([parameter]) adds parameter to WARN_CFLAGS if compiler
-# supports it. For example, use gl_WARN_ADD([-Werror]).
-AC_DEFUN([gl_WARN_ADD],
-[
- pushdef([param],[translit([$1],[ABCDEFGHIJKLMNOPQRSTUVWXYZ./-],
- [abcdefghijklmnopqrstuvwxyz___])])
+# gl_AS_VAR_IF(VAR, VALUE, [IF-MATCH], [IF-NOT-MATCH])
+#
+# Provide the functionality of AS_VAR_IF if Autoconf does not have it.
+m4_ifdef([AS_VAR_IF],
+[m4_copy([AS_VAR_IF], [gl_AS_VAR_IF])],
+[m4_define([gl_AS_VAR_IF],
+[AS_IF([test xAS_VAR_GET([$1]) = x$2], [$3], [$4])])])
- AC_CACHE_CHECK([whether compiler handles $1], [gl_cv_warn[]param[]], [
-save_CFLAGS=$CFLAGS
-CFLAGS=${CFLAGS} $1
-AC_PREPROC_IFELSE([AC_LANG_PROGRAM([])],
- gl_cv_warn[]param=yes, gl_cv_warn[]param=no)
-CFLAGS=$save_CFLAGS
- ])
+# gl_AS_VAR_APPEND(VAR, VALUE)
+#
+# Provide the functionality of AS_VAR_APPEND if Autoconf does not have it.
+m4_ifdef([AS_VAR_APPEND],
+[m4_copy([AS_VAR_APPEND], [gl_AS_VAR_APPEND])],
+[m4_define([gl_AS_VAR_APPEND],
+[AS_VAR_SET([$1], [AS_VAR_GET([$1])$2])])])
- if test $gl_cv_warn[]param = yes; then
-WARN_CFLAGS=$WARN_CFLAGS $1
- fi
+# gl_WARN_ADD(PARAMETER, [VARIABLE = WARN_CFLAGS])
+#
+# Adds parameter to WARN_CFLAGS if the compiler supports it. For example,
+# gl_WARN_ADD([-Wparentheses]).
+AC_DEFUN([gl_WARN_ADD],
+[AS_VAR_PUSHDEF([gl_Warn], [gl_cv_warn_$1])dnl
+AC_CACHE_CHECK([whether compiler handles $1], [gl_Warn], [
+ save_CFLAGS=$CFLAGS
+ CFLAGS=${CFLAGS} $1
+ AC_PREPROC_IFELSE([AC_LANG_PROGRAM([])],
+[AS_VAR_SET([gl_Warn], [yes])],
+ [AS_VAR_SET([gl_Warn], [no])])
+ CFLAGS=$save_CFLAGS
+])
+AS_VAR_PUSHDEF([gl_Flags], m4_if([$2], [], [[WARN_CFLAGS]], [[$2]]))dnl
+gl_AS_VAR_IF([gl_Warn], [yes], [gl_AS_VAR_APPEND([gl_Flags], [ $1])])
+AS_VAR_POPDEF([gl_Flags])dnl
+AS_VAR_POPDEF([gl_Warn])dnl
])
Re: warning: module to simplify adding compiler warnings
But gl_WARN_INIT should also accept a VARIABLE argument, then? Or better, make gl_WARN_INIT automatic upon the first use of gl_WARN_ADD with the given VARIABLE? You have a point; however, gl_WARN_INIT would then need a second argument for the description too, and then the user can directly use AC_ARG_VAR. Paolo
Re: warning: module to simplify adding compiler warnings
This is likely a autoconf or automake question, but since it was related to the warnings module, and some of the relevant people is on this list as well, I'm trying to raise it here: How do I get the WARN_CFLAGS variable defined in all of my Makefile's? In GnuTLS, I now use AC_CONFIG_SUBDIR for lib/ and libextra/ sub-directories. I want to add this to my top-level configure.ac: gl_WARN_ADD([-W]) and then get the WARN_CFLAGS replicated into lib/Makefile and libextra/Makefile as well. I've tried adding AC_SUBST and AC_ARG_VAR for WARN_CFLAGS in lib/configure.ac, and the variables were defined in lib/Makefile but the content was empty. Any ideas? What mechanism propagates the CFLAGS setting to sub-directories? I used to add -W etc to CFLAGS in the top-level configure.ac, and they were propagated into lib/Makefile and libextra/Makefile without problem. One solution I thought about was if I could mark WARN_CFLAGS as a similar variable to CFLAGS somehow. Thanks, /Simon
Re: warning: module to simplify adding compiler warnings
Ralf Wildenhues wrote: FWIW, I wouldn't use AC_ARG_VAR for gl_WARN_INIT. Yes, agreed: When the user wants to disable some warnings, he can do so by putting the opposite -W options into the CFLAGS when configuring. That's what my proposed piece of documentation says. Non-maintainers don't need to set different warning options on different subdirectories of the package. Bruno
Re: fdl-1.3
I added an entry to gnulib/config/srclist.txt so that fdl.texi will be synced from the gnustandards project. Having a separate copy floating around on its own can't be a good thing. karl
Re: glibc's snprintf bug causes printf(1) failure with MALLOC_PERTURB_ != 0
Jim Meyering wrote: It would be good for gnulib to detect the bug and to use the replacement snprintf on losing systems. Does the checking whether printf survives out-of-memory conditions test from gnulib (part of any of the *print-posix modules) print yes or no on the two machines you used? I chose to eliminate the shared-libraries: gcc -static -W -Wall k.c Is it necessary? Won't it crash also with dynamic linking? Then run it like this: env -i -- zsh -f -c \ 'ulimit -v 5000; MALLOC_PERTURB_=9 ./a.out %$[5*2**20]d' || dmesg|tail -1 Is the MALLOC_PERTURB_ essential for the failure or not? FYI, the libc in freebsd 6.1 and newer has no problem with the above snprintf usage. But it fails the gl_PRINTF_ENOMEM check that is already in m4/printf.m4. Bruno
