-
-
Notifications
You must be signed in to change notification settings - Fork 31.7k
Regression: test_datetime fails on 3.5, Win 7, works on 3.4 #69279
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Comments
PS C:\Users\Terry> py -3 -m test test_datetime
[1/1] test_datetime
test test_datetime failed -- Traceback (most recent call last):
File "C:\Programs\Python 3.5\lib\test\datetimetester.py", line 1154, in test_strftime
self.assertEqual(t.strftime(""), "") # SF bug python/cpython#38716
ValueError: Invalid format string Same result 3 times. |
Looks like something related to bpo-24917. |
I can reproduce. I'm bewildered as to why none of the buildbots are complaining about this. |
Interestingly, the re-run performed by regrtest's '-w' flag did not fail. |
Maybe errno needs to be explicitly cleared before calling strftime or else we're seeing someone else's EINVAL? |
(In the C code I mean, not in the test.) |
Yes, errno should always be cleared before use (in C99 at least, |
I guess when I said I'd done "exactly" what you suggested I misread that part... whoops. This is a pretty nasty bug to workaround... do we have any way for a user to clear errno from their own code? |
Clearing is easy: errno = 0; :) C library functions are not supposed to set errno to 0 by |
I get that part. Is there a way people can set errno to zero from Python code? Or do we need to ship 3.5.1 already? |
It's common in Modules/posixmodule.c to set errno to 0 before calling a C function, especially when "errno != 0" is checked after the call (because it's the only way to check if the function failed?). |
Given all the changes in the windows support in 3.5, I will not be at all surprised if we need to spin 3.5.1 much more quickly than we normally would in any case. |
Steve, sorry if I misunderstand you: My point (and eryksun's) I didn't look at this issue in depth, just pointing out a |
Argh, finally I got it: You suggested that Python users work I think it's better to release 3.5.1 early. |
The only the thing that comes to mind is using ctypes based on the CRT's implementation of errno: import ctypes
import errno
import time
ucrtbase = ctypes.CDLL('ucrtbase')
ucrtbase._errno.restype = ctypes.POINTER(ctypes.c_int)
c_errno = ucrtbase._errno().contents >>> time.strftime('')
''
>>> c_errno.value = errno.EINVAL; time.strftime('')
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
ValueError: Invalid format string |
But it should go without saying that clearing errno from Python isn't reliable considering how much code executes between Python statements. It needs to be cleared right before call strftime, and optionally the old value needs to be saved first in order to restore it, if you're concerned about that. |
I'm not worried about preserving it - strftime is supposed to be a very thin wrapper around the underlying strftime. I think David's right and we'll be shipping 3.5.1 pretty soon regardless (though a lot of the issues seem to be due to changed installation locations and have existing for a long time, just that the people who regularly change the defaults apparently haven't reported them). |
Patch attached. I haven't been able to repro the issue locally without the fix, but it seems indisputably correct behavior. We could also skip most of the function for an empty format string and save ourselves a lot of work. That would avoid the ambiguous returned "is it zero-length or is it an error" value. |
(The fix is indisputably correct, is what I meant.) |
+#if defined _MSC_VER && _MSC_VER >= 1400 && defined(STDC_SECURE_LIB) This code is too complex. Please remove the #if and always set errno to 0, on any platform! |
We don't check errno on any other platform. |
Oh ok. The code becomes more and more verbose because of Windows :-( |
Arguably it's because of the platforms that don't reliably set errno. (I don't know exactly which those are, but I'm not about to enable it everywhere right now. If someone else wants to do it and deal with the fallout they're welcome.) |
New changeset aa6b9205c120 by Steve Dower in branch '3.5': |
Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.
Show more details
GitHub fields:
bugs.python.org fields:
The text was updated successfully, but these errors were encountered: