os.popen4 and popen2.popen4 undocumented behavior

Jeff Epler jepler at unpythonic.net
Wed Sep 8 10:22:02 EDT 2004


The offending code, in Modules/posixmodule.c:_PyPclose() (indentation
decreased for clarity):
    /* Last file for this process */
    if (result != EOF &&
        WaitForSingleObject(hProcess, INFINITE) != WAIT_FAILED &&
        GetExitCodeProcess(hProcess, &exit_code)) {
            /* Possible truncation here in 16-bit environments, but
             * real exit codes are just the lower byte in any event.
             */
            result = exit_code;
Here, exit_code is apparently getting the negative number, in particular
-1.  When this is eventually returned (to Objects/fileobject.c:file_close()) 
it is treated as though the close call failed (since (on your platform)
-1 is EOF, the failure value for fclose()).

If -1 is the only value that works incorrectly, then maybe the code
in posixmodule.c should be canged to
            result = exit_code == -1 ? -2 : exit_code;
from my reading, -1 causes an error, 0 returns None, and any other value
returns an int, so this should make your test.exe return -2 on the second
close, instead of raising IOError.

Another choice would be to write 
    if(sts == EOF && errno != 0) /* raise IOError */
instead of 
    if(sts == EOF) /* raise IOError */
in fileobject.c, since a failed f_close would always set errno.  In your
case, the successful f_close returned a value that happens to equal EOF
but "succeeded" in some sense.

As far as being undocumented, under Unix os.popen4 doesn't seem to give
the return value of the called program on the close of the last part of
the pipe (all the closes return None).

If you believe one of these solutions I proposed is a good one, you
should go through the patch submission process on sourceforge, which
will eventually be reviewed by someone and possibly accepted (though
almost certainly not in time for Python 2.4.0).  If you do, please
add a test to the test suite (for Windows only, since the Unix behavior
differs) as a part of your patch.

Jeff
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 196 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/python-list/attachments/20040908/2c64ac8d/attachment.sig>


More information about the Python-list mailing list