Hi Mark, Mark H Weaver <m...@netris.org> skribis:
>> Mark H Weaver <m...@netris.org> skribis: >> >>> Here's a patch that might fix the problem, but I don't have time to test >>> it right now. >> >> It works! :-) I wrote tests and pushed it as >> ab2fd70ef1e36c6532128b73082809ef3c056556. > > On my system, I found that my proposed patch caused one of the existing > tests to fail. Which test? In commit ab2fd70ef1e36c6532128b73082809ef3c056556 I modified the test that passes \u0100 to run in a UTF-8 locale, on the grounds that the previous behavior was fragile: “raw bytes” of the input string would be preserved, but they could be mixed with things like month names in the current locale encoding. The result is rather unpredictable. > The problem is that if the format string includes characters that are > not representable in the current locale encoding, it will fail. It > seems to me that this could break existing code that currently works. > User code that uses 'strftime' might never encode the resulting string > in the locale encoding. In theory yes, but I cannot think of a scenario where the previous behavior would be “useful”, because it’s hard to even describe what it means. > I was planning to rewrite the code to scan for the '%' escapes > ourselves, to call 'strftime' for each escape sequence (without > including the surrounding text), and to concatenate the results. I think we should deprecate ‘strftime’ and ‘strptime’: (srfi srfi-19) provides similar functionality, it uses (ice-9 i18n) for the locale stuff, and it has a better API. Perhaps something we can do in 3.0? Thanks, Ludo’.
