Please review this, I'm worried that there are cases where convertitem() is returning a string that really should be overridden by the argument "help string". However, I'm worried that this change will get rid of useful messages (via the format "; help string"), when there otherwise wouldn't be. PyArg_ParseTuple when handling a string format "s", raises a TypeError when the passed string contains a NUL. However, the TypeError doesn't contain useful information. For example: syslog.syslog('hello\0there') TypeError: [priority,] message string This seems to be a thinko in Python/getargs.c at line 331: msg = convertitem(PyTuple_GET_ITEM(args, i), &format, p_va, flags, levels, msgbuf, sizeof(msgbuf), &freelist); if (msg) { seterror(i+1, msg, levels, fname, message); <<< Line 331 return cleanreturn(0, freelist); } This also applies to Python 3 trunk in line 390. I think that's supposed to be "msg" instead of "message" in the last argument. If I change it, I get:
import syslog; syslog.syslog('hello\0there') Traceback (most recent call last): File "<stdin>", line 1, in <module> TypeError: must be string without null bytes, not str
I think it's safe to change "message" to "msg" because:
"message" is the "help" string "[priority,] message string",
but "msg" contains much more useful information.
"msg" is in the "fall back if the last argument doesn't contain useful
information" argument position, but "msg" is never NULL.
"message" only is NULL if the format string doesn't contain ";".
In every case I can find in the code, convertitem() is returning a
much more useful string than the help string.
Or perhaps it should do something like:
if (msg) {
seterror(i+1, msg, levels, fname, '%s (%s)' % ( msg, message ));
Pardon my mixed C+Python, but you get the idea.
Thoughts?
Thanks,
Sean
--
[...] Premature optimization is the root of all evil.
-- Donald Knuth
Sean Reifschneider, Member of Technical Staff