Francois Gouget fgouget@free.fr writes:
Before a 64bit integer was declared as 'long long'. This means both of these prototypes would be considered to match reset_int64(long long):
WINAPI void reset_int64(INT v1, INT v2); WINAPI void reset_int64(LONGLONG v);
And indeed there were some errors. Now it means winapi_check will think the following is a correct prototype:
WINAPI void reset_int64(DOUBLE v);
Both LONGLONG and DOUBLE are rare enough in the API that checking for them is not that useful. There are a million other possible mismatches that are much more likely and that winapi_check doesn't check for.
Might be unlikely but since the previous type of error actually happened I think it is still in the realm of the possible. That's why a longlong type would be nice. Then we'd have the following types:
- word any 16 bit integer (for 16 bit APIs)
- long any 32 bit integer (or less in 32bit APIs because of padding)
- longlong any 64 bit integer (signed, unsigned, etc)
- double floating point value
- segptr segmented pointers (for 16 bit APIs)
- ptr 32bit pointer
- str 32bit pointer to an Ansi string
- wstr 32bit pointer to a Unicode string
Actually I guess this little review raises some questions:
- Do we need an integer type which is 32bit on a 32bit platform and
64bit on a 64bit platform?
- Do we need to worry about 64bit pointers? I guess ptr, str and wstr
will automatically be interpreted as 64bit pointers on a 64bit platform?
- Can we have 32bit floating point values, i.e. floats? Are these
declared as 'long'?
Actually things are not as clean as that. For instance handles are declared long even though they are actually pointers. It really doesn't matter because the only thing that is using the info is the relay debugging code that only works on x86 anyway. On other platforms all we care about is the number of arguments. If we wanted portable relay debugging then we would need a lot more info anyway, and extracting it directly from the source would be a much better approach.