You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
datetime.strftime strings can be terminated by "\x00" literals #124531
Discovered this when adding some hypothesis tests for strptime/strftime. I suspect again that if you include a null character in your datetime format string you should expect something to act weird as hell about it, but we should probably fix this anyway if it's not too costly.
I guess this makes sense if we create a C string and pass this to the C strftime function. Perhaps we should raise an error in our code if we encounter a null character in the format string.
I guess this makes sense if we create a C string and pass this to the C strftime function. Perhaps we should raise an error in our code if we encounter a null character in the format string.
I think we can just escape them and then un-escape them before returning, no?
We handle this just fine in datetime.fromisoformat:
I also think it shouldn't raise error in this case. My expectation is the strftime shouldn't care about anything that isn't datetime format specifier, so it should ignore the \x00 instead of treating it as end of string.
This approach did not work on platforms without wstrftime() because PyUnicode_EncodeLocale() does not support embedded null characters. So I was forced to write more complex and generic patch that fixes also other issues. All that remains is to write the tests, I will do it tomorrow.
Activity
JelleZijlstra commentedon Sep 25, 2024
I guess this makes sense if we create a C string and pass this to the C strftime function. Perhaps we should raise an error in our code if we encounter a null character in the format string.
pganssle commentedon Sep 25, 2024
I think we can just escape them and then un-escape them before returning, no?
We handle this just fine in
datetime.fromisoformat:Mariatta commentedon Sep 27, 2024
I also think it shouldn't raise error in this case. My expectation is the strftime shouldn't care about anything that isn't datetime format specifier, so it should ignore the
\x00instead of treating it as end of string.pythongh-124531: Fix strftime() with embedded null characters
serhiy-storchaka commentedon Oct 5, 2024
There are many other bugs in
strftime(), and I think that fixing this issue gives a key to fix #78662 and #52551.serhiy-storchaka commentedon Oct 7, 2024
This approach did not work on platforms without
wstrftime()becausePyUnicode_EncodeLocale()does not support embedded null characters. So I was forced to write more complex and generic patch that fixes also other issues. All that remains is to write the tests, I will do it tomorrow.pythongh-124531: Fix encoding issues in strftime()
pythongh-52551: Fix encoding issues in strftime()
gh-52551: Fix encoding issues in strftime() (GH-125193)
[3.13] pythongh-52551: Fix encoding issues in strftime() (pythonGH-12…
pythongh-52551: Fix encoding issues in strftime() (pythonGH-125193)
[3.13] gh-52551: Fix encoding issues in strftime() (GH-125193) (GH-12…
[3.13] pythongh-52551: Fix encoding issues in strftime() (pythonGH-12…
[3.12] gh-52551: Fix encoding issues in strftime() (GH-125193) (GH-12…
pythongh-52551: Fix encoding issues in strftime() (pythonGH-125193)