[Python-Dev] Python 2.4 extensions require VC 7.1?
"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
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
> 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
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.
More information about the Python-Dev