Skip Menu |

This queue is for tickets about the Win32-API CPAN distribution.

Report information
The Basics
Id: 39810
Status: resolved
Worked: 45 min
Priority: 0/
Queue: Win32-API

People
Owner: cosimo [...] cpan.org
Requestors: IKEGAMI [...] cpan.org
Cc:
AdminCc:

Bug Information
Severity: Normal
Broken in:
  • 0.47
  • 0.56
Fixed in: (no value)



Subject: Resulf of ::Type::Pack and ::Type::Unpack discarded
Win32::API::Type::Pack returns the packed argument while its caller expects the argument to be changed in-place. The same goes for Win32::API::Type::Unpack. I thought the fix would be simple: --------------- BEGIN Type.pm diff --------------- ... sub Pack { - my ($type, $arg) = @_; + my $type = $_[0]; + #my $arg = $_[1]; my $pack_type = packing($type); - if($pack_type eq 'p') { - $pack_type = 'Z*'; + if($pack_type eq 'c') { + DEBUG "(PM)Type::Pack: got packing 'c': leaving untouched\n"; + return; } - $arg = pack($pack_type, $arg); - - return $arg; + DEBUG "(PM)Type::Pack: packing '$type' '$pack_type' '$_[1]'\n"; + $_[1] = pack($pack_type, $_[1]); + DEBUG "(PM)Type::Pack: returning '$_[1]'\n"; } sub Unpack { - my ($type, $arg) = @_; + my $type = $_[0]; + #my $arg = $_[1]; my $pack_type = packing($type); - if($pack_type eq 'p') { - DEBUG "(PM)Type::Unpack: got packing 'p': is a pointer\n"; - $pack_type = 'Z*'; + if($pack_type eq 'c') { + #DEBUG "(PM)Type::Unpack: got packing 'c': assuming a string (XXX)\n"; + #$pack_type = 'Z*'; + DEBUG "(PM)Type::Pack: got packing 'c': leaving untouched (XXX)\n"; + return; } - DEBUG "(PM)Type::Unpack: unpacking '$pack_type' '$arg'\n"; - $arg = unpack($pack_type, $arg); - DEBUG "(PM)Type::Unpack: returning '$arg'\n"; - return $arg; + DEBUG "(PM)Type::Unpack: unpacking '$type' '$pack_type' '$_[1]'\n"; + $_[1] = unpack($pack_type, $_[1]); + DEBUG "(PM)Type::Unpack: returning '$_[1]'\n"; } ... --------------- END Type.pm diff --------------- But that that breaks USHORT* vs LPWSTR, for starters. In fact, fixing this problem would require addressing Win32::API's failure to differentiate between - a pointer to a signed/unsigned character (CHAR*/BYTE*/...) - a pointer to a buffer (LPVOID) - a pointer to a variable string (LPSTR) - a pointer to a constant string (LPCSTR) and between - a pointer to a signed/unsigned short (SHORT*/USHORT*/...) - a pointer to a variable wide string (LPWSTR) - a pointer to a constant wide string (LPCWSTR) I'm willing to work on this, but I'd need the source to API_test.dll to add tests.
Cool! This bug report falls into the "WTF? How did this ever work before?" category. I quickly went through your report, and yes, API.xs calls Win32::API::Type::(Un)Pack() with G_DISCARD, so... but is setting $_[1] enough to change the parameter in place? I should test it myself anyway. If you can work on it, well, great. Check out the public svn repo, it's hosted on googlecode, together with the full Win32 Perl libs, at http:// code.google.com/p/libwin32/ Please can you elaborate on "In fact, fixing this problem would require addressing Win32::API's failure to differentiate between ... "
Subject: Re: [rt.cpan.org #39810] Resulf of ::Type::Pack and ::Type::Unpack discarded
Date: Thu, 9 Oct 2008 12:42:25 -0400
To: bug-Win32-API [...] rt.cpan.org
From: "Eric Brine" <ikegami [...] adaelis.com>
On Wed, Oct 8, 2008 at 5:35 PM, Cosimo Streppone via RT < bug-Win32-API@rt.cpan.org> wrote: Show quoted text
> <URL: http://rt.cpan.org/Ticket/Display.html?id=39810 > > > Cool! This bug report falls into the "WTF? How did this ever work > before?" category.
I doubt it has. The prototype-less interface expects you to do your own packing and unpacking. Either people have been doing their own packing and unpacking for the prototyped interface too ***compatibility warning***, or they haven't been using the prototyped interface. The compatibility issue only exists for pointers other than string (LPSTR/LPCSTR) and buffer (LPVOID) pointers, which are fortunately very rare. I quickly went through your report, and yes, API.xs calls Show quoted text
> Win32::API::Type::(Un)Pack() with G_DISCARD, so... but is setting $_[1] > enough to change the parameter in place?
Yes, according to both code inspection and testing. If you can work on it, well, great. Check out the public svn repo, it's Show quoted text
> hosted on googlecode, together with the full Win32 Perl libs, at http:// > code.google.com/p/libwin32/ >
I would like the for API_test.dll, but I don't see it. Is bundling a binary without its source even allowed under the Perl Artistic license? Show quoted text
> Please can you elaborate on "In fact, fixing this problem would require > addressing Win32::API's failure to differentiate between ... "
Unpacking a LPVOID should leave it unchanged. Unpacking a LPSTR should truncate at the NUL. Read-only strings should work where LPCSTR is specified. - Eric
On Gio. 09 Oct. 2008 12:42:46, ikegami@adaelis.com wrote: Show quoted text
> On Wed, Oct 8, 2008 at 5:35 PM, Cosimo Streppone via RT < > bug-Win32-API@rt.cpan.org> wrote: > > I would like the for API_test.dll, but I don't see it.
The last Win32::API release that had the source code is v0.45. The svn link I sent you has all versions archived: http://code.google.com/p/libwin32/source/browse/#svn/tags/Win32- API/0.45/API_test_dll%3Fstate%3Dclosed The reason why I removed it was that it didn't build under compilers other than MSVC, and the build process failed badly. I need to work on this. My goal is to make the dll compile with all compilers and make systems. Maybe I could start by reincluding the source code into next Win32::API release. Show quoted text
> > Please can you elaborate on "In fact, fixing this problem would
require Show quoted text
> > addressing Win32::API's failure to differentiate between ... "
> > Unpacking a LPVOID should leave it unchanged. > Unpacking a LPSTR should truncate at the NUL. > Read-only strings should work where LPCSTR is specified.
Hm.
On Mer. 15 Oct. 2008 05:11:16, COSIMO wrote: Show quoted text
> Maybe I could start by reincluding the > source code into next Win32::API release.
Done in v0.57, soon on your local CPAN mirror.
Subject: Re: [rt.cpan.org #39810] Resulf of ::Type::Pack and ::Type::Unpack discarded
Date: Fri, 24 Oct 2008 05:16:11 -0400
To: bug-Win32-API [...] rt.cpan.org
From: "Eric Brine" <ikegami [...] adaelis.com>
On Wed, Oct 15, 2008 at 5:11 AM, Cosimo Streppone via RT < bug-Win32-API@rt.cpan.org> wrote: Show quoted text
I still intend to work on this. I just can't before the end of the month.
RT-Send-CC: ikegami [...] adaelis.com
On Fri Oct 24 05:16:23 2008, ikegami@adaelis.com wrote: Show quoted text
> On Wed, Oct 15, 2008 at 5:11 AM, Cosimo Streppone via RT < > bug-Win32-API@rt.cpan.org> wrote: > > > I still intend to work on this. I just can't before the end of the month.
In 0.69 the automatic un/packing bug was fixed, but because it would break API compatibility (if you unpacked it manually, accounting for a decade of this bug) for what was previously binary, to suddenly be printable, and then unpacking the printable, would be a problem. If you want automatic un/packing of buffers, create a Win32::API::More object, starting in 0.69. Therefore I am closing this bug as fixed.