in reply to Re^2: Win32::API Memory Exception with GetCommandLine() (which returns a static string)
in thread Win32::API Memory Exception with GetCommandLine() (which returns a static string)

One has to suspect, if the OP confirms he is using a mingw built version of Perl that the problem lies in there somewhere

There's a couple of different possibilities:
1)It's MinGW-built perl using MinGW-built Win32::API;
2)It's MinGW-built perl using VC-built Win32::API;

I'm in the second category (with Win32-API-0.46). I also have Win32-API-0.46 on ActiveState perl (build 819) - it is exactly the same binary as I'm running on my MinGW-built perl, but there's no GPF with ActivePerl ... which leads me to the conclusion that the problem might lie outside Win32::API.

I still get the same length discrepancy on ActivePerl - ie Inline's 20 vs Win32::API's 21.

Cheers,
Rob
  • Comment on Re^3: Win32::API Memory Exception with GetCommandLine() (which returns a static string)

Replies are listed 'Best First'.
Re^4: Win32::API Memory Exception with GetCommandLine() (which returns a static string)
by BrowserUk (Patriarch) on Jul 06, 2007 at 05:52 UTC
    I still get the same length discrepancy on ActivePerl - ie Inline's 20 vs Win32::API's 21.

    I have a vague recollection that somewhere in Win32::API, they have code to extend the length of various strings/buffers passed in and/or out by one to 'allow room for terminating nulls'.

    Maybe I'm too tired or mis-remembering, because I cannot find it now? :(


    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.
      I've just noticed that if I take the OP's code out of the batch file, it works ok (no faults) though it still returns the wrong string.

      Also, if I replace the OP's code in the batch file with:
      use Win32::API; $function = new Win32::API("kernel32", "GetCommandLine", '', 'P'); $string = $function->Call(); print "string[".length($string)."] = '$string'\n";
      then the batch file runs without error and $string no longer contains the additional trailing space - ie Win32::API and Inline are in complete agreement.

      A problem with the Import method perhaps ? ... I've never trusted it.

      Cheers,
      Rob
      Update: As BrowserUk has subsequently demonstrated, it's the pack('Z*', ...) that leads to the extra trailing space - nothing to do with Win32::API->Import() at all.

        The extra trailing space is explainable to the weird use the OP is making of pack:

        #!/usr/bin/perl -w use strict; use Win32::API; Win32::API->Import("kernel32", "LPTSTR GetCommandLine()"); my $cl = GetCommandLine(); printf "%d : '%s'\n", length( $cl ), $cl; my $cl2 = pack 'Z*', GetCommandLine(); printf "%d : '%s'\n", length( $cl2 ), $cl2; __END__ C:\test>junk3 46 : '"c:\perl\bin\perl.exe" -sw "C:\test\junk3.pl" ' 47 : '"c:\perl\bin\perl.exe" -sw "C:\test\junk3.pl" '

        I'm lost as to why the combination of pack, mingw built perl and a batch file would cause a segfault?


        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.