Hi Jim,
> At first, I was thinking of reverting most of that patch,
> and even wrote the log and committed (locally) the result.[1]
> But then I thought "What systems would suffer if I didn't?"
> Only, shall we say, "challenged" systems would suffer the added
> overhead.
The drawback of depending
At first, I was thinking of reverting most of that patch,
and even wrote the log and committed (locally) the result.[1]
But then I thought "What systems would suffer if I didn't?"
Only, shall we say, "challenged" systems would suffer the added
overhead. Overhead that is as yet only theoretical/
Bruno Haible wrote:
> Hi Paolo,
>
>> Before proceeding, however, I'm curious whether using nl_langinfo
>> (CODESET) is less precise than locale_charset on some platform. Bruno?
>
> Here's my reply to Jim from yesterday. For some reason it was apparently
> not distributed to the mailing list.
>
> H
Hi Paolo,
> Before proceeding, however, I'm curious whether using nl_langinfo
> (CODESET) is less precise than locale_charset on some platform. Bruno?
Here's my reply to Jim from yesterday. For some reason it was apparently
not distributed to the mailing list.
Hi Jim,
> @@ -893,7 +896,9 @@ in
On 01/05/2010 07:02 PM, Jim Meyering wrote:
Is langinfo.h universally available, these days?
And is CODESET always defined?
With glibc or gnulib, yes and yes. The portability to other systems is
bitrotten anyway.
Paolo
One tweak required: include unconditionally:
This cleanup is possible too. Also, the unconditional inclusion of
langinfo.h should be sent to glibc as well.
Before proceeding, however, I'm curious whether using nl_langinfo
(CODESET) is less precise than locale_charset on some platform.
Paolo Bonzini wrote:
>> One tweak required: include unconditionally:
>
> This cleanup is possible too. Also, the unconditional inclusion of
> langinfo.h should be sent to glibc as well.
Is langinfo.h universally available, these days?
And is CODESET always defined?
I didn't think so, but haven
Jim Meyering wrote:
> In comparing regcomp.c from gnulib with the one in glibc,
> I found numerous important differences:
>
>- one bug that's been fixed in gnulib for 5 years, yet not in glibc.
> I reported it here:
>http://sourceware.org/bugzilla/show_bug.cgi?id=11127
>
>- num
Jim Meyering wrote:
> Jim Meyering wrote:
>> In comparing regcomp.c from gnulib with the one in glibc,
>> I found numerous important differences:
>>
>>- one bug that's been fixed in gnulib for 5 years, yet not in glibc.
>> I reported it here:
>>http://sourceware.org/bugzilla/show_
Jim Meyering wrote:
> In comparing regcomp.c from gnulib with the one in glibc,
> I found numerous important differences:
>
>- one bug that's been fixed in gnulib for 5 years, yet not in glibc.
> I reported it here:
>http://sourceware.org/bugzilla/show_bug.cgi?id=11127
>
>- num
In comparing regcomp.c from gnulib with the one in glibc,
I found numerous important differences:
- one bug that's been fixed in gnulib for 5 years, yet not in glibc.
I reported it here:
http://sourceware.org/bugzilla/show_bug.cgi?id=11127
- numerous bugs fixed in glibc but not
11 matches
Mail list logo
