This is an archive of the discontinued LLVM Phabricator instance.

[libcxx] [Windows] Make a more proper implementation of strftime_l for mingw with msvcrt.dll
ClosedPublic

Authored by mstorsjo on Oct 29 2019, 2:37 AM.

Diff Detail

Event Timeline

mstorsjo created this revision.Oct 29 2019, 2:37 AM
rnk accepted this revision.Oct 29 2019, 3:04 PM

lgtm

This revision is now accepted and ready to land.Oct 29 2019, 3:04 PM

Adding more libcxx/runtimes maintainers, to get an ack from one of them as well before pushing.

This looks reasonable to me, but I noticed that there's a behavior difference - __libcpp_locale_guard has been added. (previously the loc parameter was ignored).

Shouldn't there be a test for this new behavior?

This looks reasonable to me, but I noticed that there's a behavior difference - __libcpp_locale_guard has been added. (previously the loc parameter was ignored).

Yes, this is the whole point of the change. The windows CRTs lack some _l suffixed functions (that can operate on any locale given as a parameter), but have functions that respect the currently set global locale. The wrappers that implement the _l suffixed functions (both this, and most of the existing ones in locale_win32.cpp) temporarily set the current thread's global locale to the desired one, execute the desired function, and then restore it on return.

Shouldn't there be a test for this new behavior?

Ideally yes, but I don't think any of the code in locale_win32.cpp actually is tested so far. E.g. localeconv_l is pretty badly broken at the moment (see D69505) - and practically speaking, I don't have a setup where I can run the runtimes tests on windows yet (I pretty much exclusively cross compile). But I guess I should work on setting that up anyway...

But regarding tests for this particular case; locales in msvcrt.dll (the old legacy one that mingw setups target by default) are extremely limited anyway (so far I've only gotten the default set "C" and the "" locale for the system-default settings to work, nothing else), and they actually can't be configured per-thread, only globally for the whole process. So this is pretty far out in the land of not really working as one would expect.

But this particular patch mostly is a case where I noticed that the current code was inconsistent (to be blamed on myself 2 years ago) and I'd like to make it more consistent.

Shouldn't there be a test for this new behavior?

I looked into the tests, and I think this codepath should be hit by existing tests in e.g. std/input.output/iostream.format/ext.manip/put_time.pass.cpp. (The test in itself doesn't work exactly as is though as msvcrt.dll, which this patch affects, provides a very limited set of locales, not including the one used by that test.)

@mclow.lists - ok to commit this one?

I'll go ahead and land this one tomorrow, before the branch; it's harmless for other configurations and makes the code more consistent. As the locale support in that crt (msvcrt.dll) is so lacking, I don't see a good way to make a meaningful testcase - the main takeaway of the change is consistency.

This revision was automatically updated to reflect the committed changes.
Herald added a project: Restricted Project. · View Herald TranscriptJan 14 2020, 12:30 PM