Message230070
| Author |
ncoghlan |
| Recipients |
christian.heimes, giampaolo.rodola, ncoghlan, r.david.murray, steve.dower |
| Date |
2014年10月27日.11:58:01 |
| SpamBayes Score |
-1.0 |
| Marked as misclassified |
Yes |
| Message-id |
<1414411082.11.0.218187888466.issue22731@psf.upfronthosting.co.za> |
| In-reply-to |
| Content |
Argh, you're making me page _testembed back into my brain. I try to avoid having to do that ;)
Anyway, this doesn't look like the right fix to me - although it may indeed be a test bug uncovered by a VC10->VC14 behavioural change in the behaviour of printf().
The origin of the output being checked is https://hg.python.org/cpython/file/default/Programs/_testembed.c#l79
Note the mixture of output from C level printf() calls and Python level print() calls inside check_stdio_details().
My guess would be that VC10 is translating '\n' to '\r\n' in the printf() calls, and VC14 has stopped doing that.
To confirm my theory: check if it is only the lines that start with "Expected" that end with '\n' rather than '\r\n' under VC14 (those are the ones produced directly from C - the others are produced via Python's print builtin).
If that *is* what's happening, we may want to convert the embedding tests over to running the subprocess in universal newlines mode, and adjust the expected output accordingly. |
|