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

"Martin v. Löwis" martin at v.loewis.de
Sat Jun 17 15:27:36 CEST 2006

Scott Dial wrote:

For fopen(3), you are right. For signal(3), VS2005 is in clear violation with ISO C I'm nobody but I don't find your argument compelling. I suggest you go read: http://msdn2.microsoft.com/en-us/library/ksazx244.aspx In short, you can tell the CRT to do whatever you like when the parameters are invalid, including returning EINVAL.

Sure, I can make the library conform to C 99. I could also write my own C library entirely to achieve that effect. The fact remains that VS 2005 violates standard C where VS 2003 and earlier did not: A conforming program will abort, instead of completing successfully.

I went back and read more of the older discussion. And I think your position is that you just don't want to force another compiler on people,

That also, yes.

but aren't developers used to this?

They can manage, sure, nobody will get injured. However, since somebody will be unhappy no matter what I do, I do what makes most people happy, i.e. no change.

Also, I'm really upset by Microsoft's attitude towards their C compiler. They shouldn't have broken the C library like that, and they shouldn't have taken the VS Express 2003 release off the net without any prior warning.

For reference, http://msdn2.microsoft.com/en-us/library/ms235497.aspx contains the list of CRT breakages according to MSFT.

Unfortunately, they don't list the specific breakage that the parameter validation causes. They don't even document the effect of parameter validation on their signal() documentation:

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/vclib/html/_CRT_signal.asp

In any case, I see little chance for a change in the build procedure for Python 2.5. Notice that none of the Python committers have spoken in favour of changing the procedure (and some against).

Regards, Martin

More information about the Python-Dev mailing list