On Sat, Sep 05, 2015 at 10:16:17AM +0200, Sebastien Marie wrote: > but be aware that some functions, like, `mblen' (used in sftp.c, so not > in same context than `utf8_ok' I think), could copte badly with > setlocale() call (man mblen extract): > > Calling any other functions in libc never change the internal state of > the mblen(), except for calling setlocale(3) with the LC_CTYPE category > changed to that of the current locale. Such setlocale(3) calls cause the > internal state of this function to be indeterminate.
Yes, there's a lot of local state in static buffers in locale-aware libc functions which don't accept mbstate_t in their argument list. For example, this state may be used to keep track of incomplete multibyte sequences between calls. Another example is keeping track of shift-states with encodings like Shift-JIS, which we don't support as a locale but which should be taken into account where portability matters. Generally, setlocale() should be called only during program startup. Somewhere at the top of main() is a good spot. Or it may not be called at all and the program stays in the C locale forever. If the program uses threads, setlocale() should be called before any threads are running. Once OpenBSD has xlocale support, threads may override their thread-specific locale settings with uselocale(). Until then, all threads will be using the same locale. That's what I make of our implementation and POSIX. I'm not sure if all this applies to every OS. But I suspect sticking with these guidelines ensures the software remains portable.
