Hi Gary,
On Mon, 18 Oct 2010, Gary V. Vaughan wrote:
> Before you put too much effort into patching the incumbent bootstrap script,
> please take a look at my complete rewrite.
I have no other plans.
> I'd be very happy for you to try it out, and let me know of your successes
> and issues in ad
Hi Paul,
On Mon, 18 Oct 2010, Paul Eggert wrote:
> How about another idea: have a very simple bootstrap script. All it
> does is fetch gnulib, and execute gnulib's more-complicated script.
We've started down that road before, but for a different initial reason.
The idea arises a few messages
On 10/22/2010 02:12 PM, Paul Eggert wrote:
On 10/22/10 12:58, Jim Meyering wrote:
Toeing the line in this case is counterproductive.
How about sticking with your improvement and instead
using this pragma in that file?
# pragma GCC diagnostic ignored "-Wtype-limits"
Hmm, Eric removed that line
On 10/22/2010 01:23 PM, Jim Meyering wrote:
Paul Eggert wrote:
> From 3a77a23690108e721b8b99f947937bda9026ee07 Mon Sep 17 00:00:00 2001
From: Paul Eggert
Date: Fri, 22 Oct 2010 11:14:17 -0700
Subject: [PATCH] inttostr: simplify by removing unnecessary redundancy
While looking into the inttostr
On 10/22/10 12:58, Jim Meyering wrote:
> Toeing the line in this case is counterproductive.
> How about sticking with your improvement and instead
> using this pragma in that file?
>
> # pragma GCC diagnostic ignored "-Wtype-limits"
Hmm, Eric removed that line about a year ago,
complaining that i
Paul Eggert wrote:
> On 10/22/10 12:23, Jim Meyering wrote:
>
>> anytostr.c:34: error: comparison of unsigned expression < 0 is always
>> false [-Wtype-limits]
>
> Hmm, I could have sworn I tested that with -Wtype-limits and it worked
> for me, but evidently I messed up (or perhaps I used a c
On 10/22/10 12:23, Jim Meyering wrote:
> anytostr.c:34: error: comparison of unsigned expression < 0 is always
> false [-Wtype-limits]
Hmm, I could have sworn I tested that with -Wtype-limits and it worked
for me, but evidently I messed up (or perhaps I used a compiler that
is not as stupid
Paul Eggert wrote:
>>From 3a77a23690108e721b8b99f947937bda9026ee07 Mon Sep 17 00:00:00 2001
> From: Paul Eggert
> Date: Fri, 22 Oct 2010 11:14:17 -0700
> Subject: [PATCH] inttostr: simplify by removing unnecessary redundancy
>
> While looking into the inttostr issues raised recently, I discovered
Eric Blake dixit:
> "If the string does not correspond to a valid locale, setlocale() shall return
> a null pointer and the international environment is not changed. Otherwise,
> setlocale() shall return the name of the locale just set."
>
> Returning a completely different string
That could be a
>From 3a77a23690108e721b8b99f947937bda9026ee07 Mon Sep 17 00:00:00 2001
From: Paul Eggert
Date: Fri, 22 Oct 2010 11:14:17 -0700
Subject: [PATCH] inttostr: simplify by removing unnecessary redundancy
While looking into the inttostr issues raised recently, I discovered
that an #if would be a bit cl
On 10/22/2010 11:47 AM, Thorsten Glaser wrote:
Eric Blake dixit:
Yikes! setlocale() is busted when handed an unrecognized locale, in that it
falls back to a completely different locale rather than failing!
MirBSD has exactly one “locale”. And from what I gathered, back then,
other implementat
Eric Blake dixit:
> Yikes! setlocale() is busted when handed an unrecognized locale, in that it
> falls back to a completely different locale rather than failing!
MirBSD has exactly one “locale”. And from what I gathered, back then,
other implementations also fall back, although, admittedly, to t
On 10/21/2010 06:06 PM, Bruno Haible wrote:
It is not formally a bug, since glibc also returns the empty string for
nl_langinfo (CRNCYSTR) in some locales (the C locale for example).
But the C locale has no currency string. POSIX is pretty clear about
CRNCYSTR:
CRNCYSTR LC_MONETARY Local
On 10/21/2010 06:21 PM, Bruno Haible wrote:
oddly enough, that doesn't include ja_JP; maybe the configure test that
learned whether ja_JP exists is broken?
Yes, it's indicating that test whether the ja_JP locale is supported is
incomplete. Can you run this program, please, and report the output
Paolo Bonzini wrote:
> > +ASSERT (strlen (currency)>= 0);
>
> Isn't this asser bogus since strlen returns size_t? Or are you just
> testing that it doesn't return rubbish?
It's a test whether the result is non-NULL and a valid pointer.
Bruno
On 10/22/2010 02:37 AM, Paolo Bonzini wrote:
On 10/22/2010 02:06 AM, Bruno Haible wrote:
+ ASSERT (strlen (currency)>= 0);
Isn't this asser bogus since strlen returns size_t? Or are you just
testing that it doesn't return rubbish?
You are indeed correct that the ASSERTION will never fail for
On 10/21/2010 07:26 PM, Eric Blake wrote:
* lib/c-stack.c (SIGSTKSZ): Increase size to avoid alternate stack
overflow on at least PowerPC64.
Signed-off-by: Eric Blake
---
If I knew of a public archives of the bug-libsigsegv list, I could
point to more details. At any rate, this patch fixes 'ma
On 10/22/2010 02:06 AM, Bruno Haible wrote:
+ASSERT (strlen (currency)>= 0);
Isn't this asser bogus since strlen returns size_t? Or are you just
testing that it doesn't return rubbish?
Paolo
18 matches
Mail list logo
