Kristján V. Jónsson wrote: > The signal() doc is rather vague on the point, since it doesn´t > define the availible set of signals. It doesn´t even say that a > signal identifier is an integer. But it says that it should return > EINVAL if it "cannot satisfy the request".
What "signal() doc" are you looking at? I'm looking at http://www.open-std.org/JTC1/SC22/WG14/www/docs/n1124.pdf section 7.14. This is ISO C99 (actually, technical corrigendum 2 of that), and it does not mention EINVAL. (BTW, signal does not *return* EINVAL, it returns SIG_ERR and sets errno). signal() isn't vague about the set of available signals. 7.14/3 lists some, then 7.14/4 says # The complete set of signals, their semantics, and their default # handling is implementation-defined; all signal numbers shall be # positive. > It doesn´t say "if the request is invalid" Ah, so you are looking at the Microsoft documentation? As the implementation isn't compliant to standard C, I would not expect their documentation to faithfully reproduce standard C. > but I don't want to go into hairsplitting here. It's an important point. If Python does not follow some relevant standard, and therefore breaks, it is Python that must be fixed. If it breaks on some system which in itself violates some standard, we have the choice of either working around or ignoring the system. > But I completely disagree when you insist that microsoft has broken > the C library. But they have. A program that is compliant to standard C used to work with earlier versions of the C library, and stops working with the current version. > What they have done is added parameter validation, > and thus simply added code in the "undefined" domain. Except that the set of supported signals is not "undefined", it's "implementation-defined". See 3.4.1 for a definition of "implementation-defined behaviour", and 3.4.3 for a definition of "undefined behaviour". > I would also > like to point out that, again apart from signal(), you are relying on > undefined behaviour of fopen and others. That is true, so we should fix Python here. > So, it is my suggestion that in stead of going all defensive, and > shouting "breakage", why not simply fix those very dubious CRT usage > patterns? Think of it as lint. Again, for fopen: sure. For signal, this is not possible: We want to set *all* signal handlers on a system, but we have know way of determining at compile time what "all signal handlers" are. Standard C is deliberately designed to allow applications to do that, and with msvcr80.dll, we can't. > Also, consider this: in the case of file() and strftime() we are > passing in dynamic strings. The strings are not within control of > python. Normally these are static strings, within the control of the > developer which has the function reference on hand, knows what he > wants and so on. Yet, here we are passing in any old strings. There > is a huge undefined domain there, and we should be very concerned > about that. It is a wonder we haven´t seen these functions crash > before. No, that's not a wonder. It's actually unfortunate that standard C did not make it an error, but they likely didn't do it because of existing practice. However, the usual, natural, straight-forward way of processing the mode string (in a loop with a switch statement) can't possible cause crashes. > (And by the way, why does pythoncore.dll mess with signal() anyway? So we can redirect all signals handlers to Python code if the user wishes so. Regards, Martin _______________________________________________ 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
