[ python-Bugs-1231069 ] ioctl has problem with -ive request codes
Bugs item #1231069, was opened at 2005-07-01 17:24 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=1231069&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Barry Alan Scott (barry-scott) Assigned to: Nobody/Anonymous (nobody) Summary: ioctl has problem with -ive request codes Initial Comment: On Linux many ioctl request code values cannot be passed to ioctl because it assumes that the values are signed ints. Value with the top bit set 0x800 are common. Changing the PyArg_ParseTuple calls to use "I" instead of "i" fixes the problem. This may well also be the issue with bug 1112949 "ioctl has problems on 64 bit machines". The attached patch fixes the problem in 2.4.1 and was tested on FC4. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1231069&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Feature Requests-1231081 ] platform.processor() could be smarter
Feature Requests item #1231081, was opened at 2005-07-01 18:38 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1231081&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Stephan Springer (tengai) Assigned to: Nobody/Anonymous (nobody) Summary: platform.processor() could be smarter Initial Comment: As far as I can see, platform.py only looks at the output of "uname -p" when platform.processor() is called. But on my system (Debian Linux), this doesn't give a result. Could you please enhance this function in a way that it also looks at /proc/cpuinfo? I'd need this to automatically find the appropriate options like "-march=..." and "-msse" for gcc/g++ in an scons script. Thanks, - Stephan. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1231081&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1028088 ] Cookies without values are silently ignored (by design?)
Bugs item #1028088, was opened at 2004-09-14 19:05
Message generated for change (Comment added) made by jjlee
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1028088&group_id=5470
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Doug Sheppard (sirilyan)
Assigned to: A.M. Kuchling (akuchling)
Summary: Cookies without values are silently ignored (by design?)
Initial Comment:
Cookie._CookiePattern is the regular expression used to
retrieve cookies from the HTTP_COOKIE environment
variable. This pattern assumes that all cookies are in
"name=value" format. A cookie that doesn't have an
"=value" component is silently skipped over. (It's
easy to generate a cookie like that - in JavaScript,
document.cookie="broken" is all it takes.)
>>> import Cookie
>>> q = Cookie.SimpleCookie("pie=good; broken;
other=thing")
>>> q
If ignoring cookies without a "=value" component is
intended behaviour, it'd be nice to have a code comment
warning that's what happens. If it's a bug, the cookie
should be set with an empty value.
--
Comment By: John J Lee (jjlee)
Date: 2005-07-01 18:22
Message:
Logged In: YES
user_id=261020
In the last sentence of my previous comment, I meant to say:
"if the latter".
--
Comment By: John J Lee (jjlee)
Date: 2005-06-29 21:02
Message:
Logged In: YES
user_id=261020
Though I had previously assumed stability is more important
than the precise details of what module Cookie does (since
you can choose what cookies you send, the only important
thing is that behaviour is relatively sane, and does the job
-- in a standards-compliant way -- with browsers). But I
suppose one can have JS code or other web app code
maintained by others, and have to understand cookies that
were emitted by that code. Is that your situation?
Do 'serious' web developers use module Cookie, or do people
now tend to use web frameworks' own cookie code (personally
I don't use cookies in my web application work). If the
former, perhaps we should not tinker with this module.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1028088&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1229788 ] Bus error in extension with gcc 3.3
Bugs item #1229788, was opened at 2005-06-29 11:43
Message generated for change (Comment added) made by tjreedy
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1229788&group_id=5470
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Extension Modules
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Gary Robinson (garyrob)
Assigned to: Nobody/Anonymous (nobody)
Summary: Bus error in extension with gcc 3.3
Initial Comment:
This text contains a c module with 4 versions of the same
extremely simple function. All they do is return a float double to
python.
On Windows I have received a report from someone who can built
the module, imported it into Python, and ran it successfully.
It has also been reported that there is no problem when the
extension is compiled with gcc 4.0 on OS X.
However, on OS X, if the extension is compiled with gcc 3.3, the 4th
of the 4 function results in a bus error:
>>> from check import *
fun0()
411.0
>>> fun1()
534.37
>>> fun2()
411.0
>>> fun3()
Bus error
I originally reported this on the C++ sig's mail list. They suggested I
try dev-python. Scott David Daniels on that list helped me refine
some
test cases and verified that they all worked on Windows.
Along the way it was suggested that I post a bug report. So this is it.
The code follows:
#include "Python.h"
static double value = 411.0;
static PyObject *
fun0(PyObject *self, PyObject *args)
{
if (!PyArg_ParseTuple(args, "", NULL)) return NULL;
return Py_BuildValue("d", value);
}
static PyObject *
fun1(PyObject *self, PyObject *args)
{
return Py_BuildValue("d", 1.3*value);
}
static PyObject *
fun2(PyObject *self, PyObject *args)
{
return PyFloat_FromDouble(value);
}
static PyObject *
fun3(PyObject *self, PyObject *args)
{
return Py_BuildValue("d", value);
}
static PyMethodDef TestMethods[] = {
{"fun0", fun0, METH_VARARGS, "Read args and return value"},
{"fun1", fun1, METH_VARARGS, "Return value multiplied inline
by
1.3"},
{"fun2", fun2, METH_VARARGS, "Return value using
PyFloat_FromDouble"},
{"fun3", fun3, METH_VARARGS, "Return value using
Py_BuildValue
without reading args -- causes bus error on OS X Panther with
XCode 1.5
installed"},
{NULL, NULL, 0, NULL}/* Sentinel */
};
PyMODINIT_FUNC
initcheck(void)
{
PyObject *module;
module = Py_InitModule3("check", TestMethods,
"extension module with three functions.");
if (module) {
PyModule_AddStringConstant(module, "__version__", "0.02");
}
}
--
>Comment By: Terry J. Reedy (tjreedy)
Date: 2005-07-01 23:13
Message:
Logged In: YES
user_id=593130
I understand that you got advice to post, but I strongly doubt that
core Python code is involved for three reasons.
1. On the Unix I used, bus errors were much rarer and esoteric
than segmentation violations (from bad pointers). But maybe
BSD-derived OSX is different.
2. The only difference between fun1 that works and fun3 that
doesn't, seems to be how the arg in computed. The receiving
function only gets a value (which it copies) and does not know its
history.
3. You report that upgrading the compiler fixes the problem. (So
why not just do that?)
If you want to experiment more, redo fun1 and fun3 with 'value'
replaced by its literal value. Then redo again with value =
534.37 instead of 411 and change arg in fun1 to
value/1.3 instead of 1.3*value.
About stack trace: On unix (of 15 years ago), program crashes
usually resulted in a file called 'core' added to either the startup
or current working directory. A debugger program could extract
a stack trace, which was more readable if the executable still had
the symbol table attached and not stripped. I don't know
equivalent for OSX, but I found it very helpful for debugging.
--
Comment By: Gary Robinson (garyrob)
Date: 2005-06-30 16:15
Message:
Logged In: YES
user_id=136420
It was reproduced by someone with Python 2.4 and gcc 3.3. So it is not
my machine.
As to closing it, a couple of people in the python C++ sig and python-dev
suggested I post it here as a bug, so I did. I'm just doing what was
requested of me. I don't mind if someone else feels it should be closed
without doing anything about it, but I don't think everyone would agree with
that action.
As for stack trace, I don't know how to look for that. All I got was the "bus
error" message. If you tell me what to look for I'll look for it.
--
Comment By: Terry J. Reedy (tjreedy)
Date: 2005-06-30 16:05
Message:
Logged In: YES
user_id=593130
Do you have any reason t
