Re^3: Win32::Clipboard and Unicode

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

Comment on Re^3: Win32::Clipboard and Unicode

Replies are listed 'Best First'.
Re: Re^3: Win32::Clipboard and Unicode by John M. Dlugosz (Monsignor) on Apr 22, 2003 at 21:14 UTC
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]

Replies are listed 'Best First'.

Re: Re^3: Win32::Clipboard and Unicode
by John M. Dlugosz (Monsignor) on Apr 22, 2003 at 21:14 UTC

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]