in reply to Re: Win32::Clipboard and Unicode
in thread Win32::Clipboard and Unicode

I suppose doing a simple patch would be easier than trying to write a valid XS from scratch, especially since the interface doesn't change.

Where can I find the source code for the current/latest version of Win32::Clipboard? (I have ActiveState Perl, which is a binary distribution. Their "source code" download AP806_source.zip doesn't contain any file named Clipboard.*)

The MS API GetClipboardData provides no way to get the length of the data returned. Quite an unfortunate design.

Hmm, it actually returns a HANDLE to a global memory block, which is as far as I can tell the only remaining use for such a thing. In Win32 HGLOBAL's have been replaced by normal memory pointers and the documentation mostly missing.

Anyway, the Win32 function GlobalSize will return the length. Do that before copying via memcpy what GlobalLock returns, instead of using a strcpy. However, it also says, “The size of a memory block may be larger than the size requested when the memory was allocated.” so perhaps this shows the rounded-up capacity, not the requested size.

If a function returned a pointer like you suggest, rather than copying it, how will Perl know to free it eventually?

To find the bytes 00 00, why not use a regex instead of a eq substr? /.*?\0\0/ or somesuch.

—John

Replies are listed 'Best First'.
Re^3: Win32::Clipboard and Unicode
by tye (Sage) on Apr 22, 2003 at 20:56 UTC

    Perhaps the returned pointer points just beyond some structure that contains the length information. That sounds familiar. It is worth investigating. My conclusions were based on rather quick checks and my not imagining that possibility.

    I have updated the (previously broken) code and so the use of substr may make more sense to you now. I assume that by using a regex to search for \0\0 you are thinking of grabbing some large chunk of data and then looking for the end. If you grab too large of a chunk, you can cause an access violation, so the only totally safe approach is to grab two more bytes each time. I'd still use index over a regex if you try that.

    I don't free the data returned and I don't recall the module doing so either. So I probably have a memory leak and the module might as well. If so, that is something else to consider fixing in your patch. (:

    As to your other reply asking about the alternative to XST_mPV() that lets you specify a length... I use a very limited set of XS items that I find are the most robust. I never access nor manipulate the stack directly and just use a return type of "SV *" and set RETVAL. You'll probably have to look up that macro in the *.h files and roll your own, probably </code>ST(0) = newSVpvn(...)</code> perhaps with some mortalization/ref-count munging.

    Some authors of Win32 modules don't bother to put their modules on CPAN. I avoid using such. Lots of Win32 modules are available on CPAN. All of my released ones are.

                    - tye
[reply]
      I don't mean to copy an arbitrary large chunk, but to do the regex on where the pointer points. I guess you can't do that directly in Perl either (I got C on the brain from reading XS).

      The module doesn't leak because the GlobalLock function isn't used, so there is no need to unlock either. I was thinking (before reading the code) that you must call GlobalLock, copy the data, then unlock, then return your copy. So returning the original pointer would be either a stale reference or a leak. Under the assumption that the handle is represented simply as a pointer to shared memory, that's not a problem. However, I don't like to make assumptions not in (or contrary to) the documentation.

[reply]

In Section Seekers of Perl Wisdom