building the dicts used to inform the user about the defined
constants when using the *conf*() APIs.
Thanks to Mark Hammond <mhammond@skippinet.com.au>.
strings to integers for the *conf*() functions.
Added code to sort the tables at module initialization. Three
dictionaries, confstr_names, sysconf_names, and pathconf_names, are
added to the module as well. These map known configuration setting
names to the numeric value which is used to represent the setting in
the system call. This code is always called.
Updated related comments.
pathconf() names, from Sjoerd.
Added code to verify that these tables are properly ordered, only
included and used when CHECK_CONFNAME_TABLES is defined. This is only
needed to test the tables, so I haven't enabled this by default.
available since the interface is poorly defined on at least one major
platform (Solaris).
Moved table of constant names for fpathconf() & pathconf() into the
conditional that defines the conv_path_confname() helper; Mark Hammond
reported that defining the table when none of the constants were
defined causes the compiler to complain (won't allow 0-length array,
imagine that!).
In posix_fpathconf(), use conv_path_confname() as the O& conversion
function, instead of the conv_confname() helper, which has the wrong
signature (posix_pathconf() already used the right thing).
and TMP_MAX.
Converted all functions that used PyArg_Parse() or PyArg_NoArgs() to
use PyArg_ParseTuple() and specified all function names using the
:name syntax in the format strings, to allow better error messages
when TypeError is raised for parameter type mismatches.
Treat them as read-only, and make a copy as appropriately. This was
first reported by Bill Janssend and later by Craig Rowland and Ron
Sedlmeyer. This fix is mine.
different values in the environ dict with the same key (although he
couldn't explain exactly how this came to be). Since getenv() uses
the first one, Python should do too. (Some doubts about case
sensitivity, but for now this at least seems the right thing to do
regardless of platform.)
f_fsid field, since it's not a scalar on all systems supporting this
call (in particular, it's a tuple of two longs on AIX). Since it's
not particularly useful, just nuke it. Adapted the doc strings too.
exceptions:
posix_error_with_filename(): New function which calls
PyErr_SetFromErrnoWithFilename()
The following methods have been changed to call
posix_error_with_filename():
posix_1str()
posix_strint()
posix_strintint()
posix_do_stat()
posix_mkdir()
posix_utime()
posix_readlink()
posix_open()
INITFUNC(): os.error (nee PosixError) is PyExc_OSError
signal handlers in a fork()ed child process when Python is compiled with
thread support. The bug was reported by Scott <scott@chronis.icgroup.com>.
What happens is that after a fork(), the variables used by the signal
module to determine whether this is the main thread or not are bogus,
and it decides that no thread is the main thread, so no signals will
be delivered.
The solution is the addition of PyOS_AfterFork(), which fixes the signal
module's variables. A dummy version of the function is present in the
intrcheck.c source file which is linked when the signal module is not
used.
(1) Use PyErr_NewException("module.class", NULL, NULL) to create the
exception object.
(2) Remove all calls to Py_FatalError(); instead, return or
ignore the errors -- the import code now checks PyErr_Occurred()
after calling a module's init function, so it's no longer a
fatal error for the initialization to fail.
Also did some small cleanups, e.g. removed unnecessary test for
"already initialized" from initfpectl(), and unified
initposix()/initnt().
I haven't checked this very thoroughly, so while the changes are
pretty trivial -- beware of untested code!