Front page | perl.libwin32 |
Postings from May 2012
Re: 3 Win32::API bugs
Thread Previous
|
Thread Next
From:
Aldo Calpini
Date:
May 9, 2012 01:35
Subject:
Re: 3 Win32::API bugs
Message ID:
4FAA2C59.1040107@perl.it
On 05/09/2012 09:23 AM, Cosimo Streppone wrote:
>> I have a few questions though, maybe you can answer them. Why is there
>> a T_INTERGER and T_NUMBER flag? I see T_INTEGER is mapped to T_NUMBER.
>> Why did T_INTEGER ever exist? or is T_INTEGER just a 4 byte integer
>> and T_NUMBER is a 4/8 byte integer?
>
> These implementation choices pre-date my involvement
> with Win32::API, so I really don't know.
>
> Maybe Aldo, the original author of Win32::API, remembers.
yes, sort of :-)
T_INTEGER performs a cast to int when preparing the parameters for the C
function call, see API.xs line 353:
params[i].l = (long_ptr) (int) SvIV(ST(i+1));
as opposed to what happens for T_NUMBER in API.xs line 281:
params[i].l = (long_ptr) SvIV(ST(i+1));
in both cases, however, the "l" member of the struct is then pushed to
the stack (that's why the params[i].t maps to T_NUMBER).
>> How is the no short problem supposed to be fixed? Moving struct to
>> letter "T" would break too many grandfathered perl scripts right? So
>> should a short be "T" then?
>
> I would definitely try to keep backward compatibility.
I was thinking about getting "$" for unsigned short. looks almost like
an S... :-)
>> Do you know what the undocumented T_POINTERPOINTER/letter 'B' is for?
>> I'm not going to remove it but just curious. I think its for a Call
>> parameter that looks like "[q|a string|]".
>
> Pointer to a pointer (ex.: char**), or in this case AV**/SV** ?
mmm, I have to admit I don't remember why this was ever needed.
looks like the code is taking a pointer from the first element of the
provided arrayref in input, and storing a pointer as second element of
the arrayref in output. but I really can't think of a possible use case
for this... it had something to do with char** for sure.
cheers,
Aldo
Thread Previous
|
Thread Next