in reply to Re^3: Can't spawn "cmd.exe":
in thread Can't spawn "cmd.exe":

The problem is with Perl's handling of Windows return codes. Trying to force fit a 32-bit signed int into an unsigned char doesn't go :)

That's quite wrong.

For starters, Windows error codes are unsigned.
ExitProcess
GetExitCodeProcess

The problem occurs when coercing the 32-bit unsigned value into 31-bits (a 32-bit signed value where negative has a special meaning).

DWORD status; ... GetExitCodeProcess(ProcessInformation.hProcess, &status); ret = (int)status;

Forcing the value into 8 bits doesn't even happen when you see that warning.

if (status < 0) { if (ckWARN(WARN_EXEC)) Perl_warner(aTHX_ packWARN(WARN_EXEC), "Can't spawn \"%s\": %s +", argv[0], strerror(errno)); status = 255 * 256; } else status *= 256; <---- coercion into 8 bits PL_statusvalue = status; }

Replies are listed 'Best First'.
Re^5: Can't spawn "cmd.exe":
by BrowserUk (Patriarch) on Mar 18, 2009 at 23:11 UTC
    For starters, Windows error codes are unsigned.

    The prototypes maybe defined as unsigned ints, but thay are treated as signed values.

    Vis: using this C program that returns its first argument as the return code:

    #include <stdlib.h> int main(int argc, _TCHAR* argv[]) { for( int i=0; i < argc; ++i ) { printf( "%d : %s\n", i, argv[ i ] ); } return atoi( argv[ 1 ] ); }

    And running this command line:

    C:\test\test\test>for /l %i in (-5, 1, 5) do test.exe %i & echo !error +level! C:\test\test\test>test.exe -5 & echo !errorlevel! 0 : test.exe 1 : -5 -5 C:\test\test\test>test.exe -4 & echo !errorlevel! 0 : test.exe 1 : -4 -4 C:\test\test\test>test.exe -3 & echo !errorlevel! 0 : test.exe 1 : -3 -3 C:\test\test\test>test.exe -2 & echo !errorlevel! 0 : test.exe 1 : -2 -2 C:\test\test\test>test.exe -1 & echo !errorlevel! 0 : test.exe 1 : -1 -1 C:\test\test\test>test.exe 0 & echo !errorlevel! 0 : test.exe 1 : 0 0 C:\test\test\test>test.exe 1 & echo !errorlevel! 0 : test.exe 1 : 1 1 C:\test\test\test>test.exe 2 & echo !errorlevel! 0 : test.exe 1 : 2 2 C:\test\test\test>test.exe 3 & echo !errorlevel! 0 : test.exe 1 : 3 3 C:\test\test\test>test.exe 4 & echo !errorlevel! 0 : test.exe 1 : 4 4 C:\test\test\test>test.exe 5 & echo !errorlevel! 0 : test.exe 1 : 5 5

    You can see that cmd.exe treats the return values as signed, otherwise the negative numbers input as strings would be returned as large positive values.

    So, your "That's quite wrong", is quite wrong.


    Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
    "Science is about questioning the status quo. Questioning authority".
    In the absence of evidence, opinion is indistinguishable from prejudice.

      So, your "That's quite wrong", is quite wrong.

      What part? You didn't contradict anything I said.

      But if it makes you happy, the following is also true.

      The problem is with Perl's handling of Windows return codes. Trying to force fit a 32-bit signed int into an unsigned char doesn't go :)

      That's quite wrong.

      The problem occurs when coercing the 32-bit unsigned value into 31 unsigned bits (a 32-bit signed value where negative has a special meaning).

      DWORD status; ... GetExitCodeProcess(ProcessInformation.hProcess, &status); ret = (int)status;

      Forcing the value into 8 bits doesn't even happen when you see that warning.

      if (status < 0) { if (ckWARN(WARN_EXEC)) Perl_warner(aTHX_ packWARN(WARN_EXEC), "Can't spawn \"%s\": %s +", argv[0], strerror(errno)); status = 255 * 256; } else status *= 256; <---- coercion into 8 bits PL_statusvalue = status; }

        You are still wrong.

        The OS does not assign negative values "a special meaning".

        Only Perl makes that mistake.

        Therefore:

        "The problem is with perl's handling of Window's return codes."
        is a correct statement.

        Equally, the OS returns 32-bits of information. Perl reduces this to 8-bits.

        Therefore:

        Trying to force fit a 32-bit signed int into an unsigned char doesn't go :)
        is also a correct statement.

        It is only your interpretation of those two statements that is wrong. Which is effectively summarised by:

        So, your "That's quite wrong", is quite wrong.

        Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
        "Science is about questioning the status quo. Questioning authority".
        In the absence of evidence, opinion is indistinguishable from prejudice.