Re: [Mingw-users] errno_t and strerror_s
-----BEGIN PGP SIGNED MESSAGE-----
On 03/12/16 00:47, DAVENPORT, MARC wrote:
> Thank you for looking into this. The whole problem arises because
> cmake incorrectly detects strerror_s in MinGW gcc 5.3.0.
No it doesn't, for GCC-5.3.0 does not provide it. However, it may
(correctly) detect it in mingwrt-3.22.x. I know users often fail to
make that distinction, but it is rather important.
> Allegro uses strerror_r and strerror_s when they are available and so
> latest Allegro from GIT fails to build because they are not actually
strerror_r() isn't, but strerror_s() actually *is*, (provided you are
prepared to sacrifice application portability to pre-Vista versions
> The call to cmake's check_function_exists(strerror_s) incorrectly
> reports it's presence.
No, it *correctly* reports its *visibility*, just as this autoconf
$ cat configure.ac
$ ./configure --host=mingw32 --build=linux
checking for mingw32-gcc... mingw32-gcc
checking whether the C compiler works... yes
checking for C compiler default output file name... a.exe
checking for suffix of executables... .exe
checking whether we are cross compiling... yes
checking for suffix of object files... o
checking whether we are using the GNU C compiler... yes
checking whether mingw32-gcc accepts -g... yes
checking for mingw32-gcc option to accept ISO C89... none needed
checking for strerror_s... yes
> This is with latest cmake installed. I plan to report it to cmake
Maybe hold off on that; I don't think cmake is at fault here. See,
both cmake and autoconf correctly detect strerror_s() *visibility*;
the issue is more that the basic tests performed are insufficient to
establish *usability*; this may require a declared prototype in some
header, which right now, MinGW lacks. Adding this would not be too
difficult, but it needs someone with incentive to make it happen;
if you wait for me to get around to it, it may take some time.
> If MinGW provided a strerror_r function it would solve this problem
As, presumably, would adding an appropriate strerror_s() prototype,
although that would, of necessity, require a feature test to restrict
its use to (user specified) _WIN32_WINNT >= _WIN32_WINNT_VISTA, thus
precluding application support for legacy platforms. It is important,
to some users, that MinGW.org continues to provide such support, and
IMO, addition of strerror_r() would be a better choice for that.
> But like you said, it needs to be thread safe.
Yes. As I noted, my tentative implementation may already fit the
bill, but it would require development of unit tests to confirm it.
Unless someone else steps forward, to help out with that, it isn't
going to happen any time soon; I simply don't have the time to do
it all on my own.
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: