Web lists-archives.com

Re: [Mingw-users] errno_t and strerror_s







On Sat, Dec 3, 2016 at 10:12 AM, Keith Marshall <keithmarshall@xxxxxxxxxxxxxxxxxxxxx> wrote:
-----BEGIN PGP SIGNED MESSAGE-----
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
  AC_INIT
  AC_PROG_CC
  AC_CHECK_FUNCS([strerror_s])

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

- --
Regards,
Keith.



Ah, okay Keith. Thanks for the clarification(s).

I see now that mingw is included in mingw/lib/*msvcr*.a but not mingw/include. I did not think to check binary archive files for its presence, rather only searched the include directory for its declaration.

Allegro strives to be forward compatible with Windows from XP on, so maybe strerror_s isn't the best choice.

I found a couple relevant pages on the web. The first discusses the thread safety of strerror and proposes a short unit test that quickly fails.

The second page shows an implementation of strerror_tls, which might be an option. It's GPL though, I don't remember MinGW's license atm. Something similar could be added without too much trouble I think. Depends on whether pthreads is native to MinGW or just optional, or whatever else MinGW does to support threads and thread local storage.

The pages are here :

http://lua-users.org/lists/lua-l/2012-03/msg00691.html

http://www.man7.org/tlpi/code/online/dist/threads/strerror_tls.c.html

I'm willing to help, for whatever its worth, but I don't have much experience with thread safety and unit tests yet. Those two pages might make for a good start though.

Marc




------------------------------------------------------------------------------
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
MinGW-users@xxxxxxxxxxxxxxxxxxxxx

This list observes the Etiquette found at 
http://www.mingw.org/Mailing_Lists.
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:
https://lists.sourceforge.net/lists/listinfo/mingw-users
Also: mailto:mingw-users-request@xxxxxxxxxxxxxxxxxxxxx?subject=unsubscribe