Web lists-archives.com

Re: [Mingw-users] errno_t and strerror_s

Hash: SHA1

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
> present.

strerror_r() isn't, but strerror_s() actually *is*, (provided you are
prepared to sacrifice application portability to pre-Vista versions
of Windows).

> 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
fragment does:

  $ cat configure.ac 

  $ autoconf
  $ ./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
> soon.

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
> nicely.

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
Version: GnuPG v2.0.20 (GNU/Linux)


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:
Also: mailto:mingw-users-request@xxxxxxxxxxxxxxxxxxxxx?subject=unsubscribe