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 u
Simon Josefsson wrote:
> Maybe also add a link to
>
> http://msdn.microsoft.com/en-us/library/ms742213(VS.85).aspx
>
> which contains much additional information?
Not needed: When googling for a function name together with
"site:msdn.microsoft.com" one immediately finds that page. Also,
URLs on
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
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
* 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
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 err
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 li
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)
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_
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
>>
> 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
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?
>>> Yo
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 ne
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 th
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 dest
>>> 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 pu
-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
-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, a
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 autoc
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
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): Substi
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
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 underst
> 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
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
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 ac
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
>> 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
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./-],
>> +
> +# 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__
Ralf Wildenhues <[EMAIL PROTECTED]> writes:
> * 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
* 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 ju
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 $CFLA
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 'e
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
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 declaratio
> 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
37 matches
Mail list logo
