Re: MT-unsafe time modules

2024-02-11 Thread Bruno Haible
This patch adds a unit test that verifies that gmtime_r and localtime_r are MT-safe. 2024-02-11 Bruno Haible time_r: Add tests. * lib/time_r.c: Add comment. * tests/test-gmtime_r.c: New file. * tests/test-gmtime_r-mt.c: New file, based on tests/test-nl_

Re: MT-unsafe time modules

2024-02-10 Thread Bruno Haible
> * These need to be made MT-safe: > > mktime, mktime-internal > timegm > > time_r > > time_rz > c-nstrftime, nstrftime > parse-datetime, parse-datetime2 For these modules, the next function to provide in an MT-safe way is localtime_r. On native Windows, when the 'localtime_s' function [1][2] i

Re: MT-unsafe time modules

2024-02-09 Thread Bruno Haible
This patch makes ctime, localtime, tzset, wcsftime multithread-safe. 2024-02-09 Bruno Haible ctime, localtime, tzset, wcsftime: Make multithread-safe. * lib/ctime.c: Include . (rpl_ctime): Modify _environ and _wenviron without using _putenv. * lib/localtime.c:

MT-unsafe time modules

2024-02-09 Thread Bruno Haible
When a module is under LGPL, it is implicitly advertised as suitable for libraries. And libraries should be MT-safe (for 20 years already). So, such modules should be MT-safe. Looking at the LGPLed time-related modules: * This one is already MT-safe: timespec * These need to be made MT-safe: s