Web lists-archives.com

Re: [Mingw-users] errno_t and strerror_s

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

- -- 

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)

#define _XOPEN_SOURCE 700

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

void show_errlist( int thread )
{ int i; const char *fmt = "%2$#010x: errno = %1$02d: %2$s\n";
  printf( "sys_errlist accessed directly from thread #%d\n\n", thread );
  for( i = 0; sys_nerr > i; i++ ) printf( fmt, i, sys_errlist[i] );
  printf( "\nsys_errlist accessed by strerror() from thread #%d\n\n", thread );
  for( i = 0; sys_nerr > i; i++ ) printf( fmt, i, strerror( i ));

void thread_proc( void *argp )
{ show_errlist( *((int *)(argp)) ); putchar( '\n' );
  sleep( 300 );

int main()
{ int i; for( i = 1; i < 5; i++ )
  { show_errlist( 0 ); putchar( '\n' );
    _beginthread( thread_proc, 0, ((void *)(&i)) );
    sleep( 10 );
  show_errlist( 0 );
  return 0;
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

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