wine/dlls wininet/wininet.spec uxtheme/uxtheme ...

[Alexandre Julliard]

Francois Gouget <fgouget at 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.

-- 
Alexandre Julliard
julliard at winehq.org