errno_t and strerror_s

classic Classic list List threaded Threaded
11 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

errno_t and strerror_s

DAVENPORT, MARC
Hello,

I was just wondering if there will ever be support for errno_t and non-standard strerror functions like strerror_s. cppreference.com says they are part of C11 and that they are included in string.h, but MinGW doesn't include them as of gcc 5.3.0 and mingwrt3.22.4 and w32api 3.18.2.

Should they be included?

I realize errno_t should just be replaced by int according to other internet sources, but the functionality of strerror_s is useful in that it duplicates the error string. It could be replaced by strerror and strdup, but strdup is non standard non strict ansi.

What should I use instead?

Marc


------------------------------------------------------------------------------

_______________________________________________
MinGW-users mailing list
[hidden email]

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:[hidden email]?subject=unsubscribe
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: errno_t and strerror_s

Keith Marshall
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 01/12/16 21:22, DAVENPORT, MARC wrote:
> I was just wondering if there will ever be support for errno_t and
> non-standard strerror functions like strerror_s.

I will not be implementing them myself, but may consider patches,
if anyone cares enough to submit them.

> cppreference.com says they are part of C11 ...

Only insofar as they are proposed[1], as *optional*, in Annex-K.

[1] AIUI, proposed by Microsoft; widely criticised, and not widely
implemented, other than by Microsoft's compilers.

> ... and that they are included in string.h, but MinGW doesn't
> include them as of gcc 5.3.0 and mingwrt3.22.4 and w32api 3.18.2.
>
> Should they be included?

Since we don't define __STDC_LIB_EXT1__, they are not required.

> I realize errno_t should just be replaced by int ...

Yes; what is the point of yet another redundant alias for int?

> ... the functionality of strerror_s is useful in that it duplicates
> the error string. It could be replaced by strerror and strdup, but
> strdup is non standard non strict ansi.

Maybe not standard in ISO-C11, but required by POSIX.1; it's provided
by the implementation, so define _POSIX_C_SOURCE appropriately, (if
you are concerned about strict standards compliance), and use it.

> What should I use instead?

As described in ISO-C11 Annex-K, strerror() and strncpy() would yield
a better match for the behaviour of strerror_s().

- --
Regards,
Keith.

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)

iQIcBAEBAgAGBQJYQKyAAAoJEMCtNsY0flo/7toP/1xzxde8EQl5IRjbS9UMcxYf
k4MiQazct2vgw2gRgnMhK+OurAxlGzK5ODv350fu5mmcZz4nwIBk7sG0GE54wvsM
ScDo8IE3Q/SLxgD17zQ4ie4htmrPJJSjC9TMB/9f6hUwgk9Upx8eRWsUrTP5den3
Foqi1tNTJAJHki+2MrrT3e393ZFhpYAVvDkp77IaeoaWa3XdtC6OyPIwztD5EkR7
3eEryASFS5AWvD4REuF2Ja7OFOBuuN26BzlAV6J7md6Alk00N1RW8T5c4MnmdGHd
60Xuy2HnFf9pVnydVEoDtFWe4GkqE2Ih76F6YN/PGYpxi2OiEEsGP2Sod5MATNEY
aKCfDfdaEswlMtk5epGoPhJnO7sJSPqHfqP72Gp5nVON3sQiBRKK/pqnOM3h8n42
sHuaFdF/qhctM+IUqV26h+oZrFUoEoelTdRmVzmTJ27uUvDC5ZFg4UFPb/ZVanoE
4uLfklrKqoODYvR/fJgY+NkO1nu8z2JoL8LZ43ir7iQUNs6WQJKI4grD/JtJvHK+
E8br6iN7ScR9JFqEazbRNL841NgQshHFaRAi0/3aOTa2C0VPIQ7LMsm0nm3sdRAZ
hnOhyKHy4rG8TBN4jjVTvRs2mPbpQNznifppG6lbi1Ckbi+2gGufxLNLEeYIpn0K
fg6WwuQprEzion8NFGf7
=ZRYN
-----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
[hidden email]

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:[hidden email]?subject=unsubscribe
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: errno_t and strerror_s

Keith Marshall
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 01/12/16 23:04, Keith Marshall wrote:
> On 01/12/16 21:22, DAVENPORT, MARC wrote:
>> What should I use instead?
>
> As described in ISO-C11 Annex-K, strerror() and strncpy() would
> yield a better match for the behaviour of strerror_s().

On further reflection, maybe snprintf() combined with strerror()
would be better still; strncpy() really isn't well suited to the
job of copying limited length initial sub-strings from a source
to a (possibly shorter) destination buffer, (because it doesn't
guarantee NUL termination, and it carries a possibly substantial
overhead, by always padding any string which does fit, with NULs,
until the destination buffer is completely filled).

Here's a tentative implementation for the strerror_r() function,
(as required by POSIX.1-2008), which, IMO offers a much better
interface design than Microsoft's strerror_s(), (because it doesn't
arbitrarily terminate your process via some overly generalized
invalid parameter handler, if you are careless about checking the
parameters you pass):

  #define _POSIX_C_SOURCE 200809L

  #include <stdio.h>
  #include <stdlib.h>
  #include <string.h>
  #include <errno.h>

  int strerror_r( int errnum, char *buf, size_t len )
  {
    if( buf == NULL )
      return errno = ERANGE;

    if( (0 > errnum) || (errnum >= sys_nerr) )
    { snprintf( buf, len, "Unknown error: %d", errnum );
      return errno = EINVAL;
    }
    if( snprintf( buf, len, "%s", strerror( errnum )) >= len )
      return errno = ERANGE;

    return 0;
  }

Do note that, as it stands, this implementation may not be thread
safe, (as it is required to be); it will be, if the pointer returned
by strerror() refers to thread-local storage, (which it may do, but I
have been unable to find any authoritative confirmation, one way or
the other); if not, then that

  snprintf( buf, len, "%s", strerror( errnum ))

call would need to be wrapped in a critical section, mutex, or some
other synchronization construct.

All that said, your idea of using strdup(), together with strerror(),
(with any synchronization construct which may be necessary), could
actually represent an even better design than either POSIX.1-2008's
strerror_r(), or Microsoft's strerror_s(); it will never truncate the
returned copy of the error message because you failed to provide a
large enough buffer; of course, you would still need to check for
failure to allocate a buffer, and when one is allocated, you should
free it when you have finished with it.

- --
Regards,
Keith.

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)

iQIcBAEBAgAGBQJYQf0vAAoJEMCtNsY0flo/+FEQALB/rpNTwxipUCuzx95bYy1V
KD7CUr3/ZIFFwcbr7a+Pfr6Ap0iCuzdptCdaGgePMjaTy14Wd21JOkhl1M4KbkoK
asRgnorn4R2lcgyeQDN7ztjRQ0EgaDtU5loz771h/2cWNyNekXwD0QuAqH3lOxIo
1NlqS1PnrCTZlo4C6fp5XhJRXvTaXb/xbh6z0/SCCY2+CD5tPKSbNFQTKKXC+8bw
+PYURZ8F072vo6iSgo0ukZnd+UfjFwt1l9NLY/2H18oOpuMuzJFHlhRaetmHsOuc
h/A+QojzOWz2YLJU/FhJuWGHvGNdgKAvQ0JN4bukupr4aW4CbdJJZR1ayGeX5d6e
W7LkufcGBkJbI1jg3xNo6LDwgggQegA2w/OvWn+6lc07WabV2BD8jo3BVS28dYcL
4duHWnfmqS+34Ta+Ehe7xP4maBQk5Enc3FkRnuwjnsVRMXkfS/YLxYXvfP6F0BDI
m88th1eJhHoHpoROQ/b+9Ctn2c3aOt7rkWs/of6kZfCBvslp92bTEU2SnH8VHeR+
PwilSbYFH65r4C2C2ZMGBW6n/pEx97xEWuFkfgElEtdSIcS2ycFOy5qKinvh7sCl
baAWHCE11kr5lturh7yptTCWsF8eKULr7P9XEaFce9On/YzKpIEawqMBQYPB9Dsv
B1pKor1CbmjOgHwLOXz5
=B/yz
-----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
[hidden email]

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:[hidden email]?subject=unsubscribe
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: errno_t and strerror_s

DAVENPORT, MARC

Keith,

Thank you for looking into this. The whole problem arises because cmake incorrectly detects strerror_s in MinGW gcc 5.3.0. 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. The call to cmake's check_function_exists(strerror_s) incorrectly reports it's presence. This is with latest cmake installed. I plan to report it to cmake soon. If MinGW provided a strerror_r function it would solve this problem nicely. But like you said, it needs to be thread safe. That's why allegro is using them. In other cases it simply reports an empty string.

Thanks for your efforts,
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
[hidden email]

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:[hidden email]?subject=unsubscribe
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: errno_t and strerror_s

Keith Marshall
-----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.

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)

iQIcBAEBAgAGBQJYQu7WAAoJEMCtNsY0flo/nF0P/2l3HZMMkjXF+LJIH/YlLEWP
vdOWgjJMEQdYMqFqjAnZ5FfopWvJspxeEa93JIrEcIzUUS26FBzNL2Geac+h1KOo
hxIVYckXALHeI6fPeqNtpKpSPJUvnh9rGBIEgyf4qjISIjnNaQZSdrHS8Ao2WFi/
NUMJmdyjfkj60fRpnt7R3AUUQuehFH5ccno1+U1aHBfqxkMjg3X4fZwRKXd0ZX4l
B5HWutZA82HhEszRQPI4eoF8yGHRWrn/RtSl71KiRBw5Rnji3Vui+nkELkYJnUZj
a0IPEg33MOjIhGJQfPiHUY1eaqGpzPD4tOX0ALMXLukhSgNYzu8rBf9aO40k28Mx
+/Gj4d0mm+2B2ElbA0pbm+75HmjsvTfujA5MnGd+Q7DvaX3ObTdtp3MIQxDze2TE
FLtkmnH87HoI/TyXpKzV/6H+pXRfFwi50+WCzI43eEaMbAyOGGnLUFj7Mvd2DtDG
DT6+BEQUL6ZNVX6NU9mHc1UTHeHA7GeJRL3PkuwSPR3+csFpYPgfk6wLxvwD2mwN
K0kp013F9LGA+xVhPw3MrUh27ZaoIlzAeo93q7yYUegxYx1VJrT3P67CzObo/Z28
eyzgTyY/QIm3ZK+OCQy7DSHurqhBn8fZYpiJy5Ne/cfWVgd0EqUKL+h9oSJRmQis
4cDymvUkI5vxRIRmbNju
=9sqY
-----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
[hidden email]

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:[hidden email]?subject=unsubscribe
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: errno_t and strerror_s

DAVENPORT, MARC



On Sat, Dec 3, 2016 at 10:12 AM, Keith Marshall <[hidden email]> 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.

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
[hidden email]

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:[hidden email]?subject=unsubscribe
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: errno_t and strerror_s

Keith Marshall
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 03/12/16 17:02, DAVENPORT, MARC wrote:
> 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:
>
> http://lua-users.org/lists/lua-l/2012-03/msg00691.html

Thanks.  Do you mean quickly fails for you, when you compile and link
it with my tentative strerror_r() implementation?  Or just that the OP
(on the Lua list) suggested that it quickly failed on his OS-X box?

FWIW, I modified it to use win32threads, (instead of pthreads), and it
does *not* fail for me, (even after several hundred million iterations
within six concurrent threads).  Frankly, given MSDN's documented use
of _sys_nerr and _sys_errlist, and assuming an implementation based on
the obvious relationship between strerror() and these two, I can see
no mechanism whereby strerror() itself could be anything other than
thread safe, provided the content of _sys_errlist remains unchanged,
(even if a single instance is shared by multiple threads).  Why might
_sys_errlist change?  Perhaps as a result of a locale change, (but the
proposed test case doesn't perform one).  However, even if I include a
setlocale() call, requesting a switch to (say) French, or German, I get
nothing but English messages, returned by strerror() on my WinXP VM,
(maybe a quirk of my primarily English language installation -- even if
I set an alternative language via control panel, the entire UI remains
resolutely in English), and the test continues to run indefinitely,
without failure.

Looks to me as if my tentative strerror_r() implementation should be
fit for purpose, unless someone can devise a more rigorous test to
prove otherwise.

- --
Regards,
Keith.

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)

iQIcBAEBAgAGBQJYRIgTAAoJEMCtNsY0flo/k84P/AsO1BuT2UzbwI6aUySqRghX
o/fdryAg/1zixrIzP7v/+wSsvhUBiG48IqbYwQn7wfI4mJ/mq6WjZfHnqtzXLzdF
Dd1WReXbmsIKwbU3nlVLmjNCIvESM9fX0XM5ElU+sHCQqXS4bTMKiNZj49sStFh7
n39y8BFy/hepmPtCIzzB9rtQtdLOy0VCqqKfPuUjKagBW8q1xQbyat9ZeGA9Dhn7
Wgpv18ERH0cGhhDH/rjjp9l3FAKzbtUXP4LU3fykcCDD2eFpzVpHjYXkaVYL12r+
d3MQWZtWxhU8mSn91ehgra+hYZLU/BxTyoSdZ4jgW1EtnqEfLqJdqqtC6eEnrjNc
0Z+K58Arerf8KhUSQzPQ2dk3kx75yCYB//O8JUyyQsnsERXa+t0GRg10nBiAlQsb
xaFqk+HR1FvI+YNt7UkTuhoXk8DrGOUhYQXXvK68VzwFhVY0EGmRGODazBND4cq1
fKtn8A0B/UJsi5W5FMWhmhjmEcqP0J8yeBOoFGprsIFuYUF5kCran8cz59sEK+Me
lUfAxHEC7tosOnYowkSSdO7vJVShiJ12yli/1XN2pjCMMrMiON2N0+2LwNsXwDtM
qM4zNRYhoBfMSsJyXOsBvXYBvMqFwfMHjxd/xUys8ExIlkIg+867idCPJOmXkG8F
e/ZXGEP+4MXaIls+NsU4
=kC6Y
-----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
[hidden email]

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:[hidden email]?subject=unsubscribe

strerror_test.c (1K) Download Attachment
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: errno_t and strerror_s

Keith Marshall
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 04/12/16 21:18, Keith Marshall wrote:
> Frankly, given MSDN's documented use of _sys_nerr and _sys_errlist,
> and assuming an implementation based on the obvious relationship
> between strerror() and these two, I can see no mechanism whereby
> strerror() itself could be anything other than thread safe, provided
> the content of _sys_errlist remains unchanged, (even if a single
> instance is shared by multiple threads).

Further experimentation, with the attached test program, does indeed
reveal that _sys_errlist represents an array of pointers to a collection
of strings, each with a fixed address, (hopefully in read-only memory),
which is shared by all threads.  However, it can also be seen that
strerror() does not simply return a direct reference into this array,
but copies the appropriate string to a static buffer, which appears to
be local to a single thread.

> Why might _sys_errlist change?  Perhaps as a result of a locale
> change, (but the proposed test case doesn't perform one).  However,
> even if I include a setlocale() call, requesting a switch to (say)
> French, or German, I get nothing but English messages, returned by
> strerror() on my WinXP VM, (maybe a quirk of my primarily English
> language installation -- even if I set an alternative language via
> control panel, the entire UI remains resolutely in English), and the
> test continues to run indefinitely, without failure.

Actually, the MSDN documentation for strerror() does not suggest that
the returned string is, in any way, locale dependent; (the lack of any
LC_MESSAGES locale category, in Windows, may be construed as a further
clue that such messages are independent of locale).

> Looks to me as if my tentative strerror_r() implementation should be
> fit for purpose, unless someone can devise a more rigorous test to
> prove otherwise.

Again, there is nothing in the MSDN documentation to suggest that
strerror() is not thread safe; there is innuendo on other sites, (such
as the notoriously ill-informed StackOverflow), which declare it to be
unsafe, but the attached program would seem to debunk such claims.

The MSDN documentation *does* warn that the content of the static
buffer returned by strerror() can be overwritten by subsequent calls
to the function, (and the attached program does indeed confirm that
this happens).  However, this does not mean that it is not thread
safe; (in fact, since each thread does appear to get its own buffer,
Microsoft's strerror() *is* thread safe); the caveat is that simply
saving the pointer returned by strerror() *doesn't* guarantee that
the message text will remain fixed, *within the calling thread*.

On this basis, if you would like to file a feature request:
https://sourceforge.net/p/mingw/bugs/new/ (so I don't forget about
it), I will consider adding strerror_r() for an upcoming release
of mingwrt-5.x

- --
Regards,
Keith.

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)

iQIcBAEBAgAGBQJYRwncAAoJEMCtNsY0flo/xAQP/R0QdglnqoTqQzEJevqGq9f6
0u7z9eCpe98SdZvR2c/1gyRoG4AWMlRMhTPAkjcGqyreKzWgx8OSGw8aFINC8668
8adi0JOGKB61dL0Vb/vHt81UPBXRF/GOaPuVs4dYEHKiq0nam57VhhEUKb9tg5im
nGm+CMen9VTsTZEq6TpEOYeueCGOBJqS+Vl4en2xt3hga8+/lBSFNGOHtkBKO4jc
VqX65nXJQGD7Gqd7JWiikGRfASjVCnKn72jC7GObfUhLOg1MtRoTNY63YLVm3DLY
BvZrcuJ2XUmPxd4pdqp+VrWfHfrDj14Hzpw+p7Uth4+FMwIjVzUoF2MHI36PvK9F
cGT+GjB8tpAZgsr0rwGzLz8HdZa6K93p2lemHRNL58GlplptaHAdvdmYRytrfM7g
32/+SecLlEexu5AWk+fMIHCPV53HmrMj97D58lwnOwkbGH4g/xjUzfTvGpwUlVbP
+jQBF0vC1CE0nzBo1H2OrRI2j2XQVgBs7Lh37Ssgs7SeMn2SIPX5VewyfQWl5OAU
JfRI1KEbV7TIR2VmAZcDign/WrhhocWkuLGa15JRLd+a8bznpFwoqlXIm4L9cF5t
dD7Yg6ntvQV4TJ1yEL1/MoHwvEjqHNFx2Eu03JsRNRIN/RDCOYbPGzyuZPQQeTC6
863ocoP9+kji80US6QWJ
=3VUN
-----END PGP SIGNATURE-----

------------------------------------------------------------------------------
Developer Access Program for Intel Xeon Phi Processors
Access to Intel Xeon Phi processor-based developer platforms.
With one year of Intel Parallel Studio XE.
Training and support from Colfax.
Order your platform today.http://sdm.link/xeonphi
_______________________________________________
MinGW-users mailing list
[hidden email]

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:[hidden email]?subject=unsubscribe

foo.c (817 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: errno_t and strerror_s

Keith Marshall
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 06/12/16 18:56, Keith Marshall wrote:
> ... in fact, since each thread does appear to get its own buffer,
> Microsoft's strerror() *is* thread safe; the caveat is that simply
> saving the pointer returned by strerror() *doesn't* guarantee that
> the message text will remain fixed, *within the calling thread*.
>
> On this basis, if you would like to file a feature request:
> https://sourceforge.net/p/mingw/bugs/new/ (so I don't forget about
> it), I will consider adding strerror_r() for an upcoming release
> of mingwrt-5.x

FWIW, I committed it anyway:
https://sourceforge.net/p/mingw/mingw-org-wsl/ci/e52d64b7f86888d5f318fae98fec0536653093d3/

- --
Regards,
Keith.

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)

iQIcBAEBAgAGBQJYnYXWAAoJEMCtNsY0flo/03sQAIzjteMU2DBew62wZQTMgVMg
zeDM/q8SI0SI9hP9HjYAlBnYH/rBmp4be81AMbsEUYESiLg9bF6XIoMahvJxMroe
i7kbIGYbqcaQHUaR7mIb+A9vNPhlfrqWXsZ7KXz5RZo9qVCLNGW1eyd6MvhbFo5f
hbYBJVfgrl3Cmoz3BuGKZ2bg+BotBxHIjgPLsTCg5ujbreyfeXuJJFPwTtCzsqw/
HUbQMgwmt4eUz3Lj7RSkWc8lm/1S3PtfIhcXE6zF3KEJhlwiWCchSpiHdFBlxS3j
oJ6uQFClVZxiJCrVSO2sZIAz2NEeQW8igPBXfeGKPDDSu0nrt4TydengmQCVGDHP
wTUlcw7JPeOoviXHr3mi+hssbKSnPmuJJFGEe2uOCamX3E4xUtG0x1rTCLOzB0kq
R2ZfnqBRRQ1G4vIXbbwzMSXeCPCcJspCqCqtMljRDXsi9A9LvV7hj/cxq6RoKjcD
n7LGXNTSYHt6ccYN2cQkav74Djdnt8E1uh2PHTkT1T7kYX9SCFINIXk5d5W/EyOk
DDCfkib9q5fchu6gCEuzxrTBA/Zy2KFKjELW+ifTn0kK83JyIG6SfphG2fk+rGKU
C0wbqrjB+xmSx4RBPlIV0qfkhx9OautNtXXApGzH66Bo7ll9vnBcMTycMgQPxWx7
vxvl0jqZkTMOCI46jMks
=sa4H
-----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
[hidden email]

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:[hidden email]?subject=unsubscribe
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: errno_t and strerror_s

DAVENPORT, MARC



On Fri, Feb 10, 2017 at 3:20 AM, Keith Marshall <[hidden email]> wrote:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 06/12/16 18:56, Keith Marshall wrote:
> ... in fact, since each thread does appear to get its own buffer,
> Microsoft's strerror() *is* thread safe; the caveat is that simply
> saving the pointer returned by strerror() *doesn't* guarantee that
> the message text will remain fixed, *within the calling thread*.
>
> On this basis, if you would like to file a feature request:
> https://sourceforge.net/p/mingw/bugs/new/ (so I don't forget about
> it), I will consider adding strerror_r() for an upcoming release
> of mingwrt-5.x

FWIW, I committed it anyway:
https://sourceforge.net/p/mingw/mingw-org-wsl/ci/e52d64b7f86888d5f318fae98fec0536653093d3/

- --
Regards,
Keith.

Thanks a lot Keith!!! I appreciate it! Sorry I forgot to file the feature request.

Any idea when you will release the next mingwrt?

Thanks, 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
[hidden email]

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:[hidden email]?subject=unsubscribe
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: errno_t and strerror_s

Keith Marshall
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 10/02/17 15:00, DAVENPORT, MARC wrote:
> Any idea when you will release the next mingwrt?

https://sourceforge.net/p/mingw/news/2017/02/mingwrt-50-and-w32api-50-snapshots-available/

- --
Regards,
Keith.

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)

iQIcBAEBAgAGBQJYoayOAAoJEMCtNsY0flo/LD8QAIIY590yDDzgKqz2g27qSSN7
86Q2DeFq9JMo+xvsuVzhTTx075spMyGH8jLe210Sqo7EzvJqBFTB/QbBO+FRksQm
g4Vpyz26QpxRftZ3yA61E8nijTMI0hD9YK+9TS7Uqfi3DZU44o2k+uT9SAhpwoN4
5u6RO/V/hxA2UMlPwJnZuD8u/9Ah10F+G0kMQgb8VfQqC6Fwe0Olnacii0l43XIy
Iw5qhsPBsfgZB/hzrTI7AGHtgvOpSX1G0j7owlGClU+fHTMv6LoEAStvWplZskzP
FFCCCI53dxZNZmpufuSGKTzHovf+s4AKSIcpWINNGjy09URoWx9vENj8l43UDgOp
s0s5wfPJHZ94BwjdY6CUsXbS1sKb0bmgC1XZ+3zPL0UuY09nkh0x6ONLA8pxaHfL
k5hzRSGuUPfLgwFHJ4Lqw8Cc+SCo+RaURBSkF3aJ0xHRlkMuDOf/YYBCOkUIHBvX
VofSJGPoKfaAb/bJgLpgJaALH4lj4N9XbTcvbcH8/sDzUZOyplyr3sUMAYK5gPTU
blZ/F3K3azDRoVxxq+dpN+Jgm3pMGjcQPHtg8pKG9A57uyuJJySY30KxZIvyk7RC
of8MoQrWeRCGMPmTw1kFCyzEHnnSwKRhnWdb2PbuX/AiaIYLkcldBFxvyM0Zs/vW
Hl/HSw69M1cHsu7s1x6l
=Lo/A
-----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
[hidden email]

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:[hidden email]?subject=unsubscribe
Loading...