Re: 3 Win32::API bugs

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