On Mon, 12 Sep 2005, Alexandre Julliard wrote:
Francois Gouget fgouget@free.fr writes:
That's from memory so it should be checked, but I believe winapi_check had a hack to check consistency between the spec file and the function prototypes in the C files. This patch likely breaks that hack, but more importantly winapi_check is going to think that the argument should be a double now :-(
A longlong would be nice.
winapi_check can be taught that a long long is specified as 'double' too. It doesn't really make sense to add a new type for the sole purpose of checking that the new type is used properly...
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);
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'?