Paul Eggert <[EMAIL PROTECTED]> wrote:
> Jim Meyering <[EMAIL PROTECTED]> writes:
>
>> This will keep me from releasing decl-after-stmt code in coreutils/src:
>
> This inspired me to try harder for an automated check for departures
> from C89. Here's a proposed patch that implements such a check f
Jim Meyering <[EMAIL PROTECTED]> writes:
> But that ChangeLog block is the one for gnulib.
Sorry about that. Here it is. I also put this into my own git
repository.
2006-11-26 Paul Eggert <[EMAIL PROTECTED]>
Improve the check for departures from C89, and fix the departures
I
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
According to Jim Meyering on 11/21/2006 7:33 AM:
>>> Would anyone be averse to switching gnulib development from CVS to git?
>>> I switched coreutils a month ago and am very happy with the result.
Based on this thread, I took a leap and ported git/cog
Hi Paul,
> --- lib/regex.h 10 Aug 2006 20:08:01 - 1.38
> +++ lib/regex.h 27 Nov 2006 07:15:02 -
> @@ -635,14 +635,17 @@
> # endif
> # endif
> #endif
> -/* gcc 3.1 and up support the [restrict] syntax. */
> -#ifndef __restrict_arr
> -# if (__GNUC__ > 3 || (__GNUC__ ==
Bruno Haible <[EMAIL PROTECTED]> writes:
> Ben Pfaff wrote:
>> C99 added some useful functions to math.h, such as trunc and
>> round. Would there be objections to a module that adds
>> implementations of those functions?
>
> This would be a good idea. Can you write it so that it augments ,
> like
Paul Eggert wrote:
Jim Meyering <[EMAIL PROTECTED]> writes:
This will keep me from releasing decl-after-stmt code in coreutils/src:
This inspired me to try harder for an automated check for departures
from C89. [snip]
Thanks, both! Since this is the most common C89 deviation (and one that
i
Some gnulib modules may want to augment noinst_LTLIBRARIES, so gnulib-tool
needs to initialize it.
2006-11-26 Bruno Haible <[EMAIL PROTECTED]>
* gnulib-tool (func_emit_lib_Makefile_am): Initialize also
noinst_LTLIBRARIES.
*** gnulib-tool.bak 2006-11-21 02:59:27.0 +
Matthew Woehlke <[EMAIL PROTECTED]> wrote:
> Paul Eggert wrote:
>> Jim Meyering <[EMAIL PROTECTED]> writes:
>>> This will keep me from releasing decl-after-stmt code in coreutils/src:
>> This inspired me to try harder for an automated check for departures
>> from C89. [snip]
>
> Thanks, both! Sinc
Now that autoconf-2.61 provides AC_COMPUTE_INT, I think the macros should
use it. As long as people are still heavily using 2.59 or 2.60, we need to
provide a fallback.
Users of autoconf-2.60a or -2.60b, please upgrade to 2.61! The signature
of AC_COMPUTE_INT has changed between 2.60a and 2.61.
O
Paul Eggert wrote:
> gettext.h also has a problem with gcc -ansi -pedantic: it uses the
> [restrict] syntax in that case, but GCC complains about it since
> [restrict] isn't in C89. Here's a proposed patch:
>
> 2006-11-26 Paul Eggert <[EMAIL PROTECTED]>
>
> * lib/gettext.h (_LIBGETTEXT_H
FYI: This bug is now fixed not only in gnulib, but also in gettext-0.16.1.
> 2006-11-20 Bruno Haible <[EMAIL PROTECTED]>
>
> * gettext.m4 (AM_GNU_GETTEXT): Revert 2005-07-28 patch: Use
> changequote instead of pairs of brackets.
> Reported by Andreas Schwab <[EMAIL PROTECTED]>
>> Can substitutes in gnulib assume that the 'double' format is IEEE 754
>> (it is on all modern platforms; VAX was the last one with other formats) ?
>> Or should they be written in a slower, but more portable way?
>
> This question is actually vital. If we can assume IEEE 754, then
> I can use i
Ben Pfaff <[EMAIL PROTECTED]> writes:
> Simon Josefsson <[EMAIL PROTECTED]> writes:
>
>> I agree in general, although I'd prefer to see gnulib support autoconf
>> 2.60a, automake 1.10 and gettext 0.15 for some time more, because that
>> is what is installed on my up-to-date Debian 'unstable' box.
Ben Pfaff wrote:
> C99 added some useful functions to math.h, such as trunc and
> round. Would there be objections to a module that adds
> implementations of those functions?
This would be a good idea. Can you write it so that it augments ,
like we do for or ?
If you're at it, you can also cont
James Youngman wrote:
> I am using gettext version 0.14.6. Its version of po/Makefile.in.in
> uses @MKINSTALLDIRS@, but the m4 files in current gnulib do not
> substitute that variable. This means that the generated po/Makefile
> contains a naked @[EMAIL PROTECTED]
>
> I think that's an incompa
Bruno Haible <[EMAIL PROTECTED]> writes:
> How about this?
That sounds good, except I prefer using < to > due to Leibnitz's
design philosophy for notation (which I learned from Val Schorre); the
style is already being used earlier in the code when checking GCC
versions. Also, when an expression
Bruno Haible <[EMAIL PROTECTED]> writes:
> Now that autoconf-2.61 provides AC_COMPUTE_INT, I think the macros should
> use it. As long as people are still heavily using 2.59 or 2.60, we need to
> provide a fallback.
Thanks, I like this change. I tested it for m4/stdint.m4, and
installed that par
Bruno Haible <[EMAIL PROTECTED]> writes:
> - I don't want to rely on __STDC_VERSION__ for the reasons explained in
> http://lists.gnu.org/archive/html/bug-gnulib/2006-10/msg00354.html,
But this case is different. Here, __STDC_VERSION__ is inspected only
if GCC 3 or later, so __STDC_VERSION
tests/test-base64.c in the gnulib repository checks out marked
executable for me. Seems odd.
--
"I didn't say it was your fault.
I said I was going to blame it on you."
Simon Josefsson wrote:
> automake 1.10 and gettext 0.15 for some time more, because that
> is what is installed on my up-to-date Debian 'unstable' box.
Ouch. automake 1.10 and gettext 0.15 don't work together. I'll talk with
the Debian guys about it. Thanks for the warning!
Bruno
Paul Eggert <[EMAIL PROTECTED]> writes:
> For other math.h functions it's a vital question, but you should be
> able to implement trunc and round portably using ceil and floor, and
> this should work correctly even for IEEE 754 hosts. Something like
> this:
>
>double
>rpl_trunc (double x)
Paul Eggert wrote:
> Matthew Woehlke <[EMAIL PROTECTED]> writes:
>
> > I could probably do it on
> > this box, but since it's Linux, it would still be with gcc.
>
> Even that would be helpful, since our current buildbot doesn't do the
> particular combination of GCC options you're interested in.
22 matches
Mail list logo
