[Python-Dev] Python 2.4 extensions require VC 7.1? (original) (raw)

"Martin v. Löwis" martin at v.loewis.de
Mon Jun 19 22:19:38 CEST 2006

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

More information about the Python-Dev mailing list