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 7.14.1.1 [#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. 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