Nothing I've tried has caused so much as a murmer of trouble:

C:\test>junkjunkjunkjunkjunkjunkxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
+xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
+xxxxxxxxxxxxxxxxxxxxxxxxxxxxxx.bat
string[178] = 'perl -x -S junkjunkjunkjunkjunkjunkxxxxxxxxxxxxxxxxxxxx
+xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
+xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx.bat  '
[download]

I'll have a go at building the latest Win32::API later today. You failed to mention which version of perl?

Do you think that garbage collection of a returned static string is incorrect?

I don't know for sure, but looking at the source code, it appears to do the right thing by copying the return value into a perl SV before returning it:

    case T_POINTER:
        ApiFunctionPointer = (ApiPointer *) ApiFunction;
        pReturn = ApiFunctionPointer();
        /* #### only works with strings... #### */
        cReturn = (char *) safemalloc(strlen(pReturn));
        strcpy(cReturn, pReturn);

        break;
...
        XSRETURN_PV(cReturn);
[download]

Which looks right as far as my nascent XS skills allow me to tell.

The one thing I didn't see was any attempt to free up the memory for the string passed--which constitutes a memory leak if you call it huge numbers of times. The following script terminates having grown to 35MB. Not that there is any point in calling this particular call multiple times as the return will never change, but it might be significant for other apis. Presumably such returned strings should be freed using Memfree() or VirtualFree() though there is no mention of this in the docs.

#!/usr/bin/perl -w
use strict;
use Win32::API;
Win32::API->Import("kernel32", "LPTSTR GetCommandLine()");

printf "\r%d : %s\t", $_, GetCommandLine() for 1 .. 1e6;
[download]

Do you get the same problems if you run the perl code directly rather than via the .bat wrapper?

Also, why are you using pack in your code? And does it help if you remove it?

(Incidently, why do you wrap it anyway?)

Thanks for the comments and investigation.

The ".bat" wrapper is used because XP/NT (and possibly still Vista) don't always redirect STDIO/STDOUT correctly for scripts executed through file associations (see http://aspn.activestate.com/ASPN/docs/ActivePerl/5.8/faq/Windows/ActivePerl-Winfaq5.html#STDIN_and_STDOUT_and_Piping_don and http://support.microsoft.com/kb/321788).

I used the "pack" because the example in Win32::API did so and I thought it might be there to fix the memory violations.

I understand the purpose of bat-wrapping (sounds like something they'd do on the Lower East Side :), but for the purposes of demonstration it seemed excessive. Of course, I now know that the problem only occured when the script, presumably reduced from the original be the problem manifest itself, is so bat-wrapped.

For the pack, I'd never notice that example before. Maybe it was necessary in early versions, and the example just never got updated.

Anyway, asked and answered. Thanks.

---

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.

"Too many [] have been sedated by an oppressive environment of political correctness and risk aversion."