Skip Menu |

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

Report information
The Basics
Id: 94906
Status: resolved
Priority: 0/
Queue: Win32-API

People
Owner: Nobody in particular
Requestors: mikko [...] noromaa.fi
Cc:
AdminCc:

Bug Information
Severity: (no value)
Broken in: (no value)
Fixed in: 0.78



Subject: Signed return values not working
Date: Mon, 21 Apr 2014 15:38:37 +0300
To: <bug-Win32-API [...] rt.cpan.org>
From: "Mikko Noromaa" <mikko [...] noromaa.fi>
Hello! I am declaring my function as follows: my $TestFunc = Win32::API->new('PerlWin32.dll', '_TestFunc@24', 'PPPPPP', 'i'); The C code looks as follows: int WINAPI TestFunc(char *str1, char *str2, char *str3, char *str4, char *str5, char *str6) { ... return (-1); } On ActiveState Perl 5.16.3 this worked fine and returned -1 to Perl. However, on ActiveState Perl 5.18.2 the function returns 4294967295. I am using Win32::API version 0.77. The same problem occurred with version 0.75 that was pre-installed with ActiveState Perl 5.18.2. When looking at perl -V, I see ActiveState has added USE_64_BIT_INT after 5.16.3. My guess is this affects the way Win32::API handles the return values. Since I am specifying 'i' (signed int), Win32::API should return -1 to Perl as -1, not as 4294967295. By the way, even 'I' (unsigned int) returned -1 on ActiveState Perl 5.16.3. -- Mikko Noromaa (mikko@noromaa.fi) - tel. +358 40 7348034
Reproduced on AP 5.18 ( USE_64_BIT_INT ) and Cygwin Perl 32 bit 5.14 (a USE_64_BIT_INT build). VC 2008 32 bit Perl (non USE_64_BIT_INT ) passes. I will investigate further
On Wed Apr 23 05:12:51 2014, BULKDD wrote: Show quoted text
> Reproduced on AP 5.18 ( USE_64_BIT_INT ) and Cygwin Perl 32 bit 5.14 > (a USE_64_BIT_INT build). VC 2008 32 bit Perl (non USE_64_BIT_INT ) > passes. I will investigate further
The problem is https://github.com/bulk88/perl5-win32-api/commit/fe878eab5bd0b52d953e209105e441eb795b0b7e turned "long_ptr" from signed into unsigned, so the 4 byte int is zero extended to 8 byte IV, not sign extended. That commit and the whole long_ptr usage needs a review to figure out how to fix this and not break something else.
fixed in 0.78