[Python-Dev] Python 2.4 extensions require VC 7.1?

"Martin v. Löwis" martin at v.loewis.de
Sat Jun 17 14:19:19 CEST 2006

Kristján V. Jónsson wrote:
> I remember you voicing this point at the Texas sprint.  I can't say I
> agree. The behaviour of certain function (like signal and fopen) is
> undefined for certain arguments.  Undefined is undefined, exiting the
> program with an admonition is one of the possible outcomes (as is
> formatting your hard drive.)

For fopen(3), you are right. For signal(3), VS2005 is in clear
violation with ISO C, which specifies in

       [#8] 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.

The set of acceptable signals is deliberately implementation-defined,
and it is consequential that an attempt to set an unsupported signal
gives an error (ISO C cannot specify that the error is EINVAL, since
EINVAL is not part of ISO C).

> In my opinion this is to be considered "a good thing" since it helps
> us adhere to the "defined" parts of the standards and not rely on
> something which is utterly unknown or unpredictable by the standards
> (but which happens to work on some platforms, no thanks to the
> standards.) Besides, we only found this an issue in three places:
> signal(), fopen() and strftime() functions.  Not a huge thing to fix.

For fopen and strftime, they could have achieved the same effect with
just setting errno to EINVAL. The C runtime library just should never
ever terminate the program unless explicitly asked to, just as Python
should never ever terminate execution without giving the application
a chance to intervene (e.g. by catching an exception).

> VS2005 also can create binaries for the X64 windows platform, no
> small point, and the primary reason we started using it in the first
> place.

OTOH, you don't *need* VS2005 to create AMD64 binaries. I had been
creating Itanium binaries for several years now with VS2003, and
started producing AMD64 binaries for Python 2.5.


More information about the Python-Dev mailing list