Hello Paul, On Sat, 17 Aug 2019 17:38:07 -0700 Paul Eggert <eggert@cs.ucla.edu> wrote:
Brian Inglis wrote:
WG14/C is looking at:
http://www.open-std.org/jtc1/sc22/wg14/www/docs/n2402.pdf
which seems somewhat based on the POSIX standard.
Thanks for the heads-up. I see that this WG14/C draft is calling localtime_r "reentrant", but it's not: in POSIX, localtime_r relies on global state to obtain the time zone, and behavior is undefined if one thread calls localtime_r while another thread is changing the time zone. Similarly for some of the other "reentrant" functions mentioned in that draft.
Right, I probably was much too optimistic :(
If WG14 wants reentrant, it should standardize localtime_rz etc. a la tzcode and NetBSD. These functions avoid the races inherent to localtime_r etc.
No, I guess that MT-safe with the specific conditions for locale and perhaps env should be enough. If I see this correctly, C itself has currently no means to change the TZ nor even an environment variable from inside the program run, so all we can do here is just to add some warnings: if the implementation permits changes to global state concerning calendar time or somehow changes the LC_TIME category, there will be trouble in a multi-threaded program execution. Seeing that, we should add some phrase to the C standard concerning strftime, too.
I'll cc. this to Jens Gustedt to give the draft's author a heads-up.
I appreciate, thanks.
Even if WG14 decides to stick with POSIXish rather than reentrant functions, the rationale document should explain why.
Locale and the interaction with threads is a can of worms, so I'd probably not open that. Thanks Jens -- :: INRIA Nancy Grand Est ::: Camus ::::::: ICube/ICPS ::: :: ::::::::::::::: office Strasbourg : +33 368854536 :: :: :::::::::::::::::::::: gsm France : +33 651400183 :: :: ::::::::::::::: gsm international : +49 15737185122 :: :: http://icube-icps.unistra.fr/index.php/Jens_Gustedt ::