Reuben Thomas asked:
> I'm interested in why you suspect MSYS would be worse than mingw? Is it
> because it is not as widely used as mingw
That is one factor. The other one is that they welcome changes that are
buggy in the long run, such as
- in MSYS1, the argv[] processing in the middle of the
On Mon, 2 May 2022 at 01:05, Bruno Haible wrote:
>
> We have documented hundreds of deficiencies of mingw [1] w.r.t. the POSIX
> standard. MSYS is surely worse, not better, than mingw. I recommend to use
> the respective modules, for those POSIX APIs that you use.
>
I'm happy to decide that on a
Reuben Thomas wrote:
> > In the end I tried something a bit different, which was to reduce the
> > > number of gnulib modules I was using, as for the code I'm writing it
> > > seemed
> > > reasonable to assume C99 and POSIX.1-2008.
> >
> > ?? That makes no sense to me. Either you want to assume PO
On Sun, 1 May 2022 at 22:34, Bruno Haible wrote:
> Reuben Thomas wrote:
> > It's not really that I'm doing anything: gnulib seems to detect MSYS as
> > being a POSIX platform.
>
> Not really; something in the configure step (which you haven't shown)
> made it "detect" some POSIX threads facility.
Reuben Thomas wrote:
> It's not really that I'm doing anything: gnulib seems to detect MSYS as
> being a POSIX platform.
Not really; something in the configure step (which you haven't shown)
made it "detect" some POSIX threads facility.
> In the end I tried something a bit different, which was to
On Sat, 30 Apr 2022 at 12:44, Bruno Haible wrote:
> Reuben Thomas wrote:
> > on MSYS it goes wrong
> > ...
> > setlocale_null_with_lock (category=category@entry=0, buf=buf@entry
> =0xbd80
> > "", bufsize=bufsize@entry=3221) at setlocale_null.c:228
> > 228 if (pthread_in_use())
> > (gdb)
Reuben Thomas wrote:
> on MSYS it goes wrong
> ...
> setlocale_null_with_lock (category=category@entry=0, buf=buf@entry=0xbd80
> "", bufsize=bufsize@entry=3221) at setlocale_null.c:228
> 228 if (pthread_in_use())
> (gdb)
> 230 pthread_mutex_t *lock = gl_get_setlocale_null_lock (
On 2019-12-18 I wrote:
> Use of setlocale(), with the gnulib override, now requires linking
> with $(LIB_SETLOCALE) - to avoid link errors on AIX.
I see such a link error on AIX:
xlC -q64 -qthreaded -qtls -DHAVE_CONFIG_H -I. -I../../gltests -I..
-DGNULIB_STRICT_CHECKING=1 -DIN_GNULIB_TESTS=1 -I
> * modules/setlocale-tests (Makefile.am): Link the test programs with
> $(LIB_SETLOCALE).
> ...
> * modules/nl_langinfo-tests (Makefile.am): Likewise.
I missed one test program that also calls setlocale().
2019-12-21 Bruno Haible
nl_langinfo tests: Fix link error (
Part of this new code in setlocale.c would also be useful for localename.c.
I'm therefore moving it to module 'setlocale-null'. At the same time, I'm
renaming the function setlocale_null to setlocale_null_r (in analogy with
getlogin_r, ttyname_r, ptsname_r).
2019-12-18 Bruno Haible
se
Ben Pfaff <[EMAIL PROTECTED]> writes:
> Bruno Haible <[EMAIL PROTECTED]> writes:
>
>> Simon Josefsson wrote:
>>> Why can we assume setlocale exists?
>>> Is it POSIX?
>>
>> Even more: It's specified by ISO C 99.
>
> Even more than that: it's in C90 also.
Yes, that's the key point: it was in ISO C9
Bruno Haible <[EMAIL PROTECTED]> writes:
> Simon Josefsson wrote:
>> Why can we assume setlocale exists?
>> Is it POSIX?
>
> Even more: It's specified by ISO C 99.
Even more than that: it's in C90 also.
--
Ben Pfaff
email: [EMAIL PROTECTED]
web: http://benpfaff.org
Bruno Haible <[EMAIL PROTECTED]> writes:
> Simon Josefsson wrote:
>> Why can we assume setlocale exists?
>
> Because we haven't encountered systems without a setlocale() for 10 years.
> The last such system that I remember was Linux libc5 5.0.xx or 5.2.xx.
>
>> Is it POSIX?
>
> Even more: It's spe
Simon Josefsson wrote:
> Why can we assume setlocale exists?
Because we haven't encountered systems without a setlocale() for 10 years.
The last such system that I remember was Linux libc5 5.0.xx or 5.2.xx.
> Is it POSIX?
Even more: It's specified by ISO C 99.
Bruno
14 matches
Mail list logo
