-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
According to Jim Meyering on 11/22/2009 1:57 AM:
> Thanks for the patch.
> How about the following instead?
> Then, if some package is defining PACKAGE specially
> and expecting that value to be used here, it will still appear.
I'd say go ahead and co
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On the cygwin list, it was pointed out that printf("%**s",1,"a","b")
proceeds to try to print "b" with a field width of whatever the integer
value of the pointer to "a" contained (or, in other words, each additional
* consumes another vararg position o
This doc update considers that MacOS X 10.5 has most of the *_l functions that
take a locale_t argument.
2009-11-24 Bruno Haible
doc: Most *_l functions exist in MacOS X 10.5.
* doc/posix-functions/duplocale.texi: Update platforms list.
* doc/posix-functions/freelocale.
Bruno Haible clisp.org> writes:
>
> Hi all,
>
> Is Windows CE [1] a reasonable portability target for GNU packages?
Probably not, unless a CeGCC developer steps up to help out on this list.
Cygwin intentionally does not run on Windows CE, and I have no interest in
porting to such a constrain
On Sun 22 Nov 2009 09:57, Jim Meyering writes:
> Thanks for the patch.
> How about the following instead?
> Then, if some package is defining PACKAGE specially
> and expecting that value to be used here, it will still appear.
Thanks for the fix. I knew that something wasn't right :)
We'll test
Hi all,
Is Windows CE [1] a reasonable portability target for GNU packages?
I'm being told that there is a free development environment called CeGCC [2].
Both the Microsoft development environment and this one provide only a
rudimentary C library: according to [3] it has even less functions than
Eric Blake byu.net> writes:
> This example flushes out the libsigsegv interaction for both cygwin 1.5 and
> today's CVS cygwin 1.7.
Given that I have proven a case where cygwin relies on internal fault handling
for more than just EFAULT, and that correct program behavior is broken if
libsigse
Hi Bruno,
Bruno Haible writes:
>> > const char *base_name = nl_langinfo (_NL_LOCALE_NAME (LC_CTYPE));
>>
>> This is not thread-safe but I guess there’s no other choice.
>
> This code is only used on glibc systems, and nl_langinfo is multithread-safe
> on glibc systems (by code inspection
Hi Ludovic,
> > const char *base_name = nl_langinfo (_NL_LOCALE_NAME (LC_CTYPE));
>
> This is not thread-safe but I guess there’s no other choice.
This code is only used on glibc systems, and nl_langinfo is multithread-safe
on glibc systems (by code inspection and due to the way it mmaps t
> + base_name = nl_langinfo (_NL_LOCALE_NAME (LC_CTYPE));
> + if (base_name[0] == '\0')
> + /* Fallback code for glibc < 2.4, which did not implement
> +nl_langinfo (_NL_LOCALE_NAME (category)). */
> + base_name = setlocale (LC_CTYPE, NULL);
Oops, the use of nl_langinf
Hi,
Eric Blake writes:
> According to Ludovic Courtès on 11/23/2009 4:01 PM:
>>> const char *base_name = nl_langinfo (_NL_LOCALE_NAME (LC_CTYPE));
>>
>> This is not thread-safe but I guess there’s no other choice.
>
> As is the case with a number of gnulib modules. But I have been trying
11 matches
Mail list logo
