Actually, I was looking at the 1989 standard which is what we are supposed to be using, right? But the exact wording in 99 is: "If the request can be honored, the signal function returns the value of func for the most recent successful call to signal for the specified signal sig. Otherwise, a value of SIG_ERR is returned and a positive value is stored in errno.". Sorry for meitioning EINVAL, my mistake.
Continuing the hairsplitting: Note that the standard doesn´t specify the valid signals, they are implementation defined as you say. and in that sense, any old integer cannot be considered a "signal sig" in the above quote. So stricly speaking (in my interpretation) there is nothing wrong in aborting for an integer that isn´t defined to be a signal by the implementation. However: Let´s just agree that signal() isn´t up to spec, and leave it out of the discussion. There are provisions all over the code for particular quirks of particular platforms. Everything else appears to be up to spec. > However, the usual, natural, straight-forward way of processing the mode > string (in a loop with a > switch statement) can't possible cause crashes. Making assumptions about how someone implements the CRT is not good practice. Relying on the implementors to go above and beyond the spec to ensure stability or some "common sense" behaviour is inviting trouble. We should be wary, not just on microsoft platforms, on treading onto domain that isn't defined. Anything can happen. Literally. But if you expect that, then in that sense, the VC8 implementation is probably better than most. Because they have gone out of their way to try to identify all possible ways that you can violate the domain of those functions, and do something defined if you do. So the behavior of these functions is defined for much wider range of input than for most other implementations, in other words, they have gone above and beyond the spec. > So we can redirect all signals handlers to Python code if the user wishes so. I wonder. Setting process wide handlers like that seems to be odd if you are embedding python to do scripting for you. The main app is usually the one that decides on signal handling for various things. Seems like a python.exe thing to me. But never mind. At the very least one should then only set those handlers that are valid for each implementation. I'd also like to draw your attention to lines 1162 and onwards in timemodule.c, lines 410 onwards. Here is an example of us forcing values into an acceptable range, although the standard says: "If any of the specified values is outside the normal range, the characters stored are unspecified.". But on some platforms it would crash, not just store unspecified values. So we are already compensating for implementations that break the standard (I think we can agree that this is breakage). So, if I agree with you that signal() is broken (by default, but mended by our fix) is there any any other technical reason why VC8 should not be taken into the fold? After all, it has already pointed out to us that we are dangerously allowing user format strings to propagate. Cheers, Kristján _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
