GitLab

[ 1077106 ] Negative numbers to os.read() cause segfault

Sorry for sitting on this for so long!  Is there a chance it could
make 2.3.5?

Also revise a related function to minimise file handle/pipe leakage
and improve reliability.

detection to configure &c.

a few remaining calls to signal() were converted to PyOS_setsig().

don't.

error msgs.

in first column, no parens around return value).

(reported by Thomas Heller).  If have_unicode_filename is set,
path looks like it will not be used, so there's no need to free it.

PyArg_ParseTuple() since the format is "et"  This change should
be reviewed carefully.

Bugfix candidate.

Will backport to 2.3.

with major C compilers (VACPP, EMX+gcc and [Open]Watcom).

Also tidy up the export of spawn*() symbols in the os module to match what
is found/implemented.

Remove BAD_EXEC_PROTOYPE (leftover from IRIX 4 demolition).

failure on FreeBSD.

Fixes #703198. Backported to 2.3.

(From SF patch #810751)

* Py_BuildValue("(OOO)",a,b,c)  -->  PyTuple_Pack(3,a,b,c)
* Py_BuildValue("()",a)         -->  PyTuple_New(0)
* Py_BuildValue("O", a)         -->  Py_INCREF(a)

(Contributed by Andrew Gaul.)

Fixes a minor leak.

Will also check in on the 2.3 branch.

docs here are best-guess:  the MS docs I could find weren't clear, and
some even claimed _commit() has no effect on Win32 systems (which is
easily shown to be false just by trying it).

popen[234]() code

  string does what is expected (ie unset [BEGIN|END]LIBPATH)

- set the size of the DosQuerySysInfo buffer correctly; it was safe,
  but incorrect (allowing a 1 element overrun)