[ python-Bugs-1112856 ] patch 1079734 broke cgi.FieldStorage w/ multipart post req.
Bugs item #1112856, was opened at 2005-01-31 01:58
Message generated for change (Comment added) made by jlgijsbers
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1112856&group_id=5470
Category: Python Library
Group: Python 2.5
Status: Open
Resolution: None
Priority: 5
Submitted By: Irmen de Jong (irmen)
Assigned to: Nobody/Anonymous (nobody)
Summary: patch 1079734 broke cgi.FieldStorage w/ multipart post req.
Initial Comment:
Patch 1079734 "Make cgi.py use email instead of rfc822
or mimetools" seems to have broken the cgi.FieldStorage
in cases where the request is a multipart post (for
instance, when a file upload form field is used).
See the attached test program.
With cgi.py revision <1.83 (python 2.4 for instance) I
get the expected results;
374
FieldStorage(None, None, [FieldStorage('param1', None,
'Value of param1'), FieldStorage('param2', None, 'Value
of param2'), FieldStorage('file', '', ''),
FieldStorage(None, None, '')])
but with cgi.py rev 1.83 (current) I get this:
374
FieldStorage(None, None, [FieldStorage('param1', None,
'')])
Another thing that I observed (which isn't reproduced
by this test program) is that cgi.FieldStorage.__init__
never completes when the fp is a socket-file (and the
request is again a multipart post). It worked fine with
the old cgi.py.
--
>Comment By: Johannes Gijsbers (jlgijsbers)
Date: 2005-02-04 11:15
Message:
Logged In: YES
user_id=469548
Here's a patch. We're interested in two things in the
patched loop:
* the rest of the multipart/form-data, including the headers
for the current part, for consumption by HeaderParser (this
is the tail variable)
* the rest of the multipart/form-data without the headers
for the current part, for consumption by FieldStorage (this
is the message.get_payload() call)
Josh, Irmen, do you see any problems with this patch?
(BTW, this fix should be ported to the parse_multipart
function as well, when I check it in (and I should make
cgibug.py into a test))
--
Comment By: Josh Hoyt (joshhoyt)
Date: 2005-02-04 08:21
Message:
Logged In: YES
user_id=693077
The email.HeaderParser module that is now used for parsing
headers consumes the rest of the body of the message when it
is used. If there was some way of telling the parser to stop
reading when it got to the end of the headers, I think this
problem would be fixed. Unfortunately, there is no external
interface to the email module's parser that lets us do this.
I hope we can come up with a reasonable solution that does
not involve reverting to using deprecated modules.
Thanks for the test case.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1112856&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1112856 ] patch 1079734 broke cgi.FieldStorage w/ multipart post req.
Bugs item #1112856, was opened at 2005-01-30 16:58
Message generated for change (Comment added) made by joshhoyt
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1112856&group_id=5470
Category: Python Library
Group: Python 2.5
Status: Open
Resolution: None
Priority: 5
Submitted By: Irmen de Jong (irmen)
Assigned to: Nobody/Anonymous (nobody)
Summary: patch 1079734 broke cgi.FieldStorage w/ multipart post req.
Initial Comment:
Patch 1079734 "Make cgi.py use email instead of rfc822
or mimetools" seems to have broken the cgi.FieldStorage
in cases where the request is a multipart post (for
instance, when a file upload form field is used).
See the attached test program.
With cgi.py revision <1.83 (python 2.4 for instance) I
get the expected results;
374
FieldStorage(None, None, [FieldStorage('param1', None,
'Value of param1'), FieldStorage('param2', None, 'Value
of param2'), FieldStorage('file', '', ''),
FieldStorage(None, None, '')])
but with cgi.py rev 1.83 (current) I get this:
374
FieldStorage(None, None, [FieldStorage('param1', None,
'')])
Another thing that I observed (which isn't reproduced
by this test program) is that cgi.FieldStorage.__init__
never completes when the fp is a socket-file (and the
request is again a multipart post). It worked fine with
the old cgi.py.
--
Comment By: Josh Hoyt (joshhoyt)
Date: 2005-02-04 07:45
Message:
Logged In: YES
user_id=693077
Johannes, your patch looks fine to me. It would be nice if
we didn't have to keep reading back each part from the
parsed message, though.
I had an idea for another approach. Use email to parse the
MIME message fully, then convert it to FieldStorage fields.
Parsing could go something like:
== CODE ==
from email.FeedParser import FeedParser
parser = FeedParser()
# Create bogus content-type header...
parser.feed('Content-type: %s ; boundary=%s \r\n\r\n' %
(self.type, self.innerboundary))
parser.feed(self.fp.read())
message = parser.close()
# Then take parsed message and convert to FieldStorage fields
== END CODE ==
This lets the email parser handle all of the complexities of
MIME, but it does mean that we have to accurately re-create
all of the necessary headers. I can cook up a full patch if
anyone thinks this would fly.
--
Comment By: Johannes Gijsbers (jlgijsbers)
Date: 2005-02-04 02:15
Message:
Logged In: YES
user_id=469548
Here's a patch. We're interested in two things in the
patched loop:
* the rest of the multipart/form-data, including the headers
for the current part, for consumption by HeaderParser (this
is the tail variable)
* the rest of the multipart/form-data without the headers
for the current part, for consumption by FieldStorage (this
is the message.get_payload() call)
Josh, Irmen, do you see any problems with this patch?
(BTW, this fix should be ported to the parse_multipart
function as well, when I check it in (and I should make
cgibug.py into a test))
--
Comment By: Josh Hoyt (joshhoyt)
Date: 2005-02-03 23:21
Message:
Logged In: YES
user_id=693077
The email.HeaderParser module that is now used for parsing
headers consumes the rest of the body of the message when it
is used. If there was some way of telling the parser to stop
reading when it got to the end of the headers, I think this
problem would be fixed. Unfortunately, there is no external
interface to the email module's parser that lets us do this.
I hope we can come up with a reasonable solution that does
not involve reverting to using deprecated modules.
Thanks for the test case.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1112856&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1112856 ] patch 1079734 broke cgi.FieldStorage w/ multipart post req.
Bugs item #1112856, was opened at 2005-01-31 01:58
Message generated for change (Comment added) made by irmen
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1112856&group_id=5470
Category: Python Library
Group: Python 2.5
Status: Open
Resolution: None
Priority: 5
Submitted By: Irmen de Jong (irmen)
Assigned to: Nobody/Anonymous (nobody)
Summary: patch 1079734 broke cgi.FieldStorage w/ multipart post req.
Initial Comment:
Patch 1079734 "Make cgi.py use email instead of rfc822
or mimetools" seems to have broken the cgi.FieldStorage
in cases where the request is a multipart post (for
instance, when a file upload form field is used).
See the attached test program.
With cgi.py revision <1.83 (python 2.4 for instance) I
get the expected results;
374
FieldStorage(None, None, [FieldStorage('param1', None,
'Value of param1'), FieldStorage('param2', None, 'Value
of param2'), FieldStorage('file', '', ''),
FieldStorage(None, None, '')])
but with cgi.py rev 1.83 (current) I get this:
374
FieldStorage(None, None, [FieldStorage('param1', None,
'')])
Another thing that I observed (which isn't reproduced
by this test program) is that cgi.FieldStorage.__init__
never completes when the fp is a socket-file (and the
request is again a multipart post). It worked fine with
the old cgi.py.
--
>Comment By: Irmen de Jong (irmen)
Date: 2005-02-04 23:06
Message:
Logged In: YES
user_id=129426
Johannes: while your patch makes my cgibug.py test case run
fine, it has 2 problems:
1- it runs much slower than the python2.4 code (probably
because of the reading back thing Josh is talking about);
2- it still doesn't fix the second problem that I observed:
cgi.FieldStorage never completes when fp is a socket. I
don't have a separate test case for this yet, sorry.
So Josh: perhaps your idea doesn't have these 2 problems?
--
Comment By: Josh Hoyt (joshhoyt)
Date: 2005-02-04 16:45
Message:
Logged In: YES
user_id=693077
Johannes, your patch looks fine to me. It would be nice if
we didn't have to keep reading back each part from the
parsed message, though.
I had an idea for another approach. Use email to parse the
MIME message fully, then convert it to FieldStorage fields.
Parsing could go something like:
== CODE ==
from email.FeedParser import FeedParser
parser = FeedParser()
# Create bogus content-type header...
parser.feed('Content-type: %s ; boundary=%s \r\n\r\n' %
(self.type, self.innerboundary))
parser.feed(self.fp.read())
message = parser.close()
# Then take parsed message and convert to FieldStorage fields
== END CODE ==
This lets the email parser handle all of the complexities of
MIME, but it does mean that we have to accurately re-create
all of the necessary headers. I can cook up a full patch if
anyone thinks this would fly.
--
Comment By: Johannes Gijsbers (jlgijsbers)
Date: 2005-02-04 11:15
Message:
Logged In: YES
user_id=469548
Here's a patch. We're interested in two things in the
patched loop:
* the rest of the multipart/form-data, including the headers
for the current part, for consumption by HeaderParser (this
is the tail variable)
* the rest of the multipart/form-data without the headers
for the current part, for consumption by FieldStorage (this
is the message.get_payload() call)
Josh, Irmen, do you see any problems with this patch?
(BTW, this fix should be ported to the parse_multipart
function as well, when I check it in (and I should make
cgibug.py into a test))
--
Comment By: Josh Hoyt (joshhoyt)
Date: 2005-02-04 08:21
Message:
Logged In: YES
user_id=693077
The email.HeaderParser module that is now used for parsing
headers consumes the rest of the body of the message when it
is used. If there was some way of telling the parser to stop
reading when it got to the end of the headers, I think this
problem would be fixed. Unfortunately, there is no external
interface to the email module's parser that lets us do this.
I hope we can come up with a reasonable solution that does
not involve reverting to using deprecated modules.
Thanks for the test case.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1112856&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1116520 ] Prefix search is filesystem-centric
Bugs item #1116520, was opened at 2005-02-04 17:16 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1116520&group_id=5470 Category: Python Interpreter Core Group: None Status: Open Resolution: None Priority: 4 Submitted By: Steve Holden (holdenweb) Assigned to: Nobody/Anonymous (nobody) Summary: Prefix search is filesystem-centric Initial Comment: With the introduction of zipimport I experimented to determine how much of the standard library could be provided in zip format. I discovered that I could entirely remove the standard library, replacing it with /lib/python24.zip, with the following caveats (this is under Cygwin, where /usr/lib appears to be a loopback mount of /lib: paths will differ on other platforms): 1. The /lib/python2.4/lib-dynload directory had to be copied to the /lib directory to make zlib available to zipimport; 2. The interpreter now produced three error messages: "Could not find platform independent libraries " "Could not find platform dependent libraries " "Consider setting $PYTHONHOME to [:]" With the move towards esoteric import mechanisms it seems that the searches for os.py in the filesystem might no longer be an appropriate way to start executing the interpreter. Should some import hook API be available to determine whether standard libraries are available without actually importing anything? -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1116520&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1053687 ] PyOS_InputHook not called in subprocess
Bugs item #1053687, was opened at 2004-10-25 07:31 Message generated for change (Settings changed) made by kbk You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1053687&group_id=5470 >Category: IDLE >Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Michiel de Hoon (mdehoon) >Assigned to: Kurt B. Kaiser (kbk) Summary: PyOS_InputHook not called in subprocess Initial Comment: PyOS_InputHook is a variable points to a user-defined function (e.g. in an extension module) that is to be called periodically when Python is idle (e.g. waiting for user input). It is used for example by Tkinter to get messages delivered to the graphics window. For Python run from the command prompt, PyOS_InputHook (if not NULL) is called ten times per second. In IDLE, when a subprocess is being used (so the default behavior), the main process and the subprocess each have their own PyOS_InputHook. The problem is that the subprocess (the one that runs the user's commands) does not call PyOS_InputHook. So if a user (in IDLE) imports an extension module that sets PyOS_InputHook, the extension module will not run correctly as PyOS_InputHook is being ignored. The solution to this problem is probably quite simple, maybe just a line if (PyOS_InputHook) PyOS_InputHook(); but I am not familiar enough with threads to be able to figure out what the best location for such a line would be. I tried putting it inside the loop in PyEval_EvalFrame in Python/ceval.c, which solved the problem on some platforms but not on others. --Michiel. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1053687&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1112856 ] patch 1079734 broke cgi.FieldStorage w/ multipart post req.
Bugs item #1112856, was opened at 2005-01-30 16:58
Message generated for change (Comment added) made by joshhoyt
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1112856&group_id=5470
Category: Python Library
Group: Python 2.5
Status: Open
Resolution: None
Priority: 5
Submitted By: Irmen de Jong (irmen)
Assigned to: Nobody/Anonymous (nobody)
Summary: patch 1079734 broke cgi.FieldStorage w/ multipart post req.
Initial Comment:
Patch 1079734 "Make cgi.py use email instead of rfc822
or mimetools" seems to have broken the cgi.FieldStorage
in cases where the request is a multipart post (for
instance, when a file upload form field is used).
See the attached test program.
With cgi.py revision <1.83 (python 2.4 for instance) I
get the expected results;
374
FieldStorage(None, None, [FieldStorage('param1', None,
'Value of param1'), FieldStorage('param2', None, 'Value
of param2'), FieldStorage('file', '', ''),
FieldStorage(None, None, '')])
but with cgi.py rev 1.83 (current) I get this:
374
FieldStorage(None, None, [FieldStorage('param1', None,
'')])
Another thing that I observed (which isn't reproduced
by this test program) is that cgi.FieldStorage.__init__
never completes when the fp is a socket-file (and the
request is again a multipart post). It worked fine with
the old cgi.py.
--
Comment By: Josh Hoyt (joshhoyt)
Date: 2005-02-04 15:02
Message:
Logged In: YES
user_id=693077
Irmen, can you try to create a test case where the
cgi.FieldStorage never completes, so I can make sure that
any fix I come up with resolves it?
I will try to put together an implementation where the email
parser parses the whole multipart message.
--
Comment By: Irmen de Jong (irmen)
Date: 2005-02-04 14:06
Message:
Logged In: YES
user_id=129426
Johannes: while your patch makes my cgibug.py test case run
fine, it has 2 problems:
1- it runs much slower than the python2.4 code (probably
because of the reading back thing Josh is talking about);
2- it still doesn't fix the second problem that I observed:
cgi.FieldStorage never completes when fp is a socket. I
don't have a separate test case for this yet, sorry.
So Josh: perhaps your idea doesn't have these 2 problems?
--
Comment By: Josh Hoyt (joshhoyt)
Date: 2005-02-04 07:45
Message:
Logged In: YES
user_id=693077
Johannes, your patch looks fine to me. It would be nice if
we didn't have to keep reading back each part from the
parsed message, though.
I had an idea for another approach. Use email to parse the
MIME message fully, then convert it to FieldStorage fields.
Parsing could go something like:
== CODE ==
from email.FeedParser import FeedParser
parser = FeedParser()
# Create bogus content-type header...
parser.feed('Content-type: %s ; boundary=%s \r\n\r\n' %
(self.type, self.innerboundary))
parser.feed(self.fp.read())
message = parser.close()
# Then take parsed message and convert to FieldStorage fields
== END CODE ==
This lets the email parser handle all of the complexities of
MIME, but it does mean that we have to accurately re-create
all of the necessary headers. I can cook up a full patch if
anyone thinks this would fly.
--
Comment By: Johannes Gijsbers (jlgijsbers)
Date: 2005-02-04 02:15
Message:
Logged In: YES
user_id=469548
Here's a patch. We're interested in two things in the
patched loop:
* the rest of the multipart/form-data, including the headers
for the current part, for consumption by HeaderParser (this
is the tail variable)
* the rest of the multipart/form-data without the headers
for the current part, for consumption by FieldStorage (this
is the message.get_payload() call)
Josh, Irmen, do you see any problems with this patch?
(BTW, this fix should be ported to the parse_multipart
function as well, when I check it in (and I should make
cgibug.py into a test))
--
Comment By: Josh Hoyt (joshhoyt)
Date: 2005-02-03 23:21
Message:
Logged In: YES
user_id=693077
The email.HeaderParser module that is now used for parsing
headers consumes the rest of the body of the message when it
is used. If there was some way of telling the parser to stop
reading when it got to the end of the headers, I think this
problem would be fixed. Unfortunately, there is no external
interface to the email module's parser that lets us do this.
I hope we can come up with a reasonable solution that does
not involve reverting to using deprecated modules.
Thanks for the test case.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1112856&group_id=5470
_
[ python-Bugs-1075984 ] Memory fault pyexpat.so on SGI
Bugs item #1075984, was opened at 2004-11-30 05:13
Message generated for change (Comment added) made by bos
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1075984&group_id=5470
Category: XML
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Maik Hertha (mhertha)
Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: Memory fault pyexpat.so on SGI
Initial Comment:
I build the latest RC1 of python 2.4.
System SGI Fuel IP35, Irix 6.5.26m
cc -version
MIPSpro Compilers: Version 7.3.1.3m
- make tests passes test_pyexpat without error
- running this code leads to a core dump
-- code ---
import xml.dom.minidom
doc = xml.dom.minidom.parseString(fstream)
<<< core dump >>>
--- runing python -v test.py
#
/opt/python24c1/lib/python2.4/xml/dom/expatbuilder.pyc
matches
/opt/python24c1/lib/python2.4/xml/dom/expatbuilder.py
import xml.dom.expatbuilder # precompiled from
/opt/python24c1/lib/python2.4/xml/dom/expatbuilder.pyc
import xml.parsers # directory
/opt/python24c1/lib/python2.4/xml/parsers
#
/opt/python24c1/lib/python2.4/xml/parsers/__init__.pyc
matches
/opt/python24c1/lib/python2.4/xml/parsers/__init__.py
import xml.parsers # precompiled from
/opt/python24c1/lib/python2.4/xml/parsers/__init__.pyc
# /opt/python24c1/lib/python2.4/xml/parsers/expat.pyc
matches /opt/python24c1/lib/python2.4/xml/parsers/expat.py
import xml.parsers.expat # precompiled from
/opt/python24c1/lib/python2.4/xml/parsers/expat.pyc
dlopen("/opt/python24c1/lib/python2.4/lib-dynload/pyexpat.so",
2);
Memory fault(coredump)
- running this code from an interactive session leads
not to a coredump
I need some assistance howto provide further debug
information.
--maik./
--
Comment By: Bryan O'Sullivan (bos)
Date: 2005-02-04 15:16
Message:
Logged In: YES
user_id=28380
With the GNU linker, you can pass in -Bstatic to force it to resolve the
symbols in the local shared library, instead of globally. This also works on
Irix. I don't know about other Unixes.
--
Comment By: Michael Hudson (mwh)
Date: 2005-02-02 02:35
Message:
Logged In: YES
user_id=6656
It's a nasty one, I'll give you that.
Fred, what do you think of bos's patch? It solves the immediate issue,
but I'm not sure it's a complete fix.
It seems to me that it would be better to resolve the expat symbols at
builf time, but I don't know how to arrange for that.
--
Comment By: Bryan O'Sullivan (bos)
Date: 2005-02-01 22:09
Message:
Logged In: YES
user_id=28380
By the way, this is not an SGI-specific bug. This will bite any Unix system
with a modern sysv-style dynamic linker. The priority of this bug should be
higher, IMO.
--
Comment By: Bryan O'Sullivan (bos)
Date: 2005-01-31 23:53
Message:
Logged In: YES
user_id=28380
I've been bitten by the same bug. In my case, the problem was with Qt, not GTK.
It's not actually necessary to check the expat version; just see if
XML_ErrorString actually returns anything.
Here's the patch I use for this problem:
--- python/Modules/pyexpat.c2005-01-06 16:26:13 -08:00
+++ python/Modules/pyexpat.c 2005-01-31 23:46:36 -08:00
@@ -1936,9 +1936,12 @@
}
#endif
-#define MYCONST(name) -PyModule_AddStringConstant(errors_module, #name, -
(char*)XML_ErrorString(name))
+#define MYCONST(name) +{ +char *_v =
(char*)XML_ErrorString(name); +if (_v) +
PyModule_AddStringConstant(errors_module, #name, _v); +}
MYCONST(XML_ERROR_NO_MEMORY);
MYCONST(XML_ERROR_SYNTAX);
--
Comment By: Stephen Watson (kerofin)
Date: 2004-12-13 05:46
Message:
Logged In: YES
user_id=471223
pyexpat initializes using its internal copy of expat.
libexpat.so is still mapped in (after pyexpat has
initilized), but gdb finds the python copy of
XML_ErrorString and other functions.
I suspect that this will be a problem if the system version
of expat is newer than Python's.
--
Comment By: Michael Hudson (mwh)
Date: 2004-12-13 05:01
Message:
Logged In: YES
user_id=6656
1) Good sleuthing.
2) Argh!
3) What happens if you import pyexpat before pygtk?
--
Comment By: Stephen Watson (kerofin)
Date: 2004-12-13 01:29
Message:
Logged In: YES
user_id=471223
I've looked at the program that was dumping core and the
sequence is this:
1) Program imports pygtk, which links in the GTK libraries
2) Program loads SVG image which links in librsvg.so which
in turn links in /usr/local/lib/libexpat.so
3) Program imports pyexpat.
4) pye
[ python-Bugs-1116571 ] Wrong match with regex, non-greedy problem
Bugs item #1116571, was opened at 2005-02-05 01:12 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1116571&group_id=5470 Category: Regular Expressions Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: rengel (engel_re) Assigned to: Gustavo Niemeyer (niemeyer) Summary: Wrong match with regex, non-greedy problem Initial Comment: # This is executable. # My test string ist rather long: tst = "In this Buch, used to designate Dinge der Wirklichkeit rather than SW Ent." # I want to match the last part of the string: # SW Ent # So I define the following pattern an compile it: pat = r"(.*?) (.*?)" rex = re.compile(pat) # Then I search the string to get a match group : mat = rex.search(tst) # If found, print the group if mat: print mat.group() # Instead of # SW Ent # I get the whole string starting with # Buch... # up to the very last # Apparently the non-greedy operator doesn't work correctly. # What's wrong? -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1116571&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1116722 ] Solaris 10 fails to compile complexobject.c
Bugs item #1116722, was opened at 2005-02-04 23:02 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1116722&group_id=5470 Category: Build Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Case Van Horsen (casevh) Assigned to: Nobody/Anonymous (nobody) Summary: Solaris 10 fails to compile complexobject.c Initial Comment: This is a duplicate of 970334. The fix I used was to make the following change in pyport.h: Change #define Py_HUGE_VAL HUGE_VAL to #define PY_HUGE_VAL DBL_MAX. DBL_MAX is found in float.h Versions used: Python 2.4 gcc 3.4.3 Solaris 10 x86 GA release. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1116722&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1116722 ] Solaris 10 fails to compile complexobject.c [FIX incl.]
Bugs item #1116722, was opened at 2005-02-04 23:02 Message generated for change (Settings changed) made by casevh You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1116722&group_id=5470 Category: Build Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Case Van Horsen (casevh) Assigned to: Nobody/Anonymous (nobody) >Summary: Solaris 10 fails to compile complexobject.c [FIX incl.] Initial Comment: This is a duplicate of 970334. The fix I used was to make the following change in pyport.h: Change #define Py_HUGE_VAL HUGE_VAL to #define PY_HUGE_VAL DBL_MAX. DBL_MAX is found in float.h Versions used: Python 2.4 gcc 3.4.3 Solaris 10 x86 GA release. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1116722&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
