Actually, I was looking at the 1989 standard which is what we are supposed to
be using, right? But the exact wording in 99 is:
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
Kristján V. Jónsson wrote:
However, the usual, natural, straight-forward way of processing the
mode string (in a loop with a switch statement) can't possible
cause crashes.
Making assumptions about how someone implements the CRT is not good
practice.
I'm not arguing about that, and I think
extensions require VC 7.1?
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
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python
: [Python-Dev] Python 2.4 extensions require VC 7.1?
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
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
Giovanni Bajo wrote:
It was discussed before, and the agreement was to use VS 2003 for another
cycle
(i.e. 2.5). But the fact that VS 2003 is no longer available for download is
an
important fact, and we might want to rediscuss the issue.
it's still available in the .net sdk packages (see
Giovanni Bajo wrote:
It was discussed before, and the agreement was to use VS 2003 for another
cycle
(i.e. 2.5). But the fact that VS 2003 is no longer available for download is
an
important fact, and we might want to rediscuss the issue.
I don't recall the discussion vividly, but I think
Fredrik Lundh wrote:
It was discussed before, and the agreement was to use VS 2003 for another
cycle
(i.e. 2.5). But the fact that VS 2003 is no longer available for download is
an
important fact, and we might want to rediscuss the issue.
it's still available in the .net sdk packages
Scott Dial wrote:
I don't recall the discussion vividly, but I think the reasoning was
something like because it still works. Maybe I remember wrong, but
this is not a compelling argument en lieu of it being hard to get a hold
of the toolkit. If there is some kind of legwork involved with
suggestions and comments on how to better automate the
PGO build process
Cheers,
Kristján
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Martin v. Löwis
Sent: 17. júní 2006 08:26
To: Scott Dial
Cc: Python Dev
Subject: Re: [Python-Dev] Python 2.4 extensions
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
Martin v. Löwis 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
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
One reason for not switching to VC 8, which hasn't yet been explicitly
mentioned here, is that MinGW does not yet easily support linking to the
msvcr80 runtime library. Some C extension modules, for instance those in
SciPy, are primarily developed under Linux with GCC and hence are most
easily
Op za, 17-06-2006 te 10:25 +0200, schreef Martin v. Löwis:
Another reason is that I consider VS 2005 buggy, I hope that some
of the breakage that Microsoft has done to the C library is reverted
in a future release. VS2005 managed to break compatibility with
C89 and C99 in a way that made
Jan Claeys wrote:
Op za, 17-06-2006 te 10:25 +0200, schreef Martin v. Löwis:
Another reason is that I consider VS 2005 buggy, I hope that some
of the breakage that Microsoft has done to the C library is reverted
in a future release. VS2005 managed to break compatibility with
C89 and C99 in a
A colleague recently posted this message:
I'm trying to build a Python extension, and Python 2.4 insists on the MS
Visual C++ compiler version 7.1, which is included with the MS VC++ 2003
toolkit. This toolkit is no longer available for download from
Microsoft (superseded by the 2005
Bill Janssen [EMAIL PROTECTED] wrote:
I'm trying to build a Python extension, and Python 2.4 insists on
the MS
Visual C++ compiler version 7.1, which is included with the MS VC++
2003
toolkit. This toolkit is no longer available for download from
Microsoft (superseded by the 2005 version),
18 matches
Mail list logo