Re: [Mingw-users] Problems compiling Gnulib-assisted projects with MinGW runtime 3.22.2
- Date: Wed, 12 Oct 2016 14:47:20 +0100
- From: Keith Marshall <keithmarshall@xxxxxxxxxxxxxxxxxxxxx>
- Subject: Re: [Mingw-users] Problems compiling Gnulib-assisted projects with MinGW runtime 3.22.2
-----BEGIN PGP SIGNED MESSAGE-----
On 11/10/16 07:34, Eli Zaretskii wrote:
> "Whine"? I think this was uncalled for, and completely
I don't understand your objection. You, yourself, described it as a
"gripe"; "whine" and "gripe" are colloquially synonymous, but to me,
"whine" just seems a more natural choice for the verb. There was no
> A MinGW-compiled GDB 7.12 is available for MinGW users, regardless
> of the problems I bumped into, just 2 days since it was released.
> I posted my message only after I built and uploaded it. How is
> that "whining"?
In the sense of "persistent complaining" it isn't, but did you file a
bug report against GDB, for its gratuitous violation of the applicable
standards, by assuming that strcasecmp() and strncasecmp() should be
declared in <string.h>, rather than in <strings.h> where they belong?
Indeed, the declarations in glibc's <string.h> would appear to be an
anachronistic aberration ... allegedly to support BSD usage. However,
the strcasecmp(3) manpages for the three common BSD distributions,
FreeBSD, OpenBSD, and NetBSD, all agree that <strings.h> is correct.
All add the historical annotation that the two functions made their
first appearances in 4.4BSD; FreeBSD adds the qualification:
> The strcasecmp() and strncasecmp() functions first appeared in
> 4.4BSD. Their prototypes existed previously in <string.h> before
> they were moved to <strings.h> for IEEE Std 1003.1-2001
> (``POSIX.1'') compliance.
so, the claimed BSD support in glibc is "archaic legacy", at best;
today, any dependence on it really should be considered a bug.
I accept that MinGW may not be considered sufficiently important to
persuade upstream projects to fix this bug, but surely the three main
BSD distributions would be? You really should file that bug report,
(especially since you obviously know how to resolve it).
Public key available from keys.gnupg.net
Key fingerprint: C19E C018 1547 DE50 E1D4 8F53 C0AD 36C6 347E 5A3F
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.20 (GNU/Linux)
-----END PGP SIGNATURE-----
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
MinGW-users mailing list
This list observes the Etiquette found at
We ask that you be polite and do the same. Disregard for the list etiquette may cause your account to be moderated.
You may change your MinGW Account Options or unsubscribe at: