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
