Alexandre Julliard wrote:
Log message: Specify 64-bit integers as double instead of long long in spec files so that we get the correct number of arguments.
Wouldn't it be better to extend the spec format to allow for a longlong type instead?
Robert Shearman rob@codeweavers.com writes:
Wouldn't it be better to extend the spec format to allow for a longlong type instead?
I considered doing that, but I decided it would just add complexity for no real reason. If we really need more detailed parameter info then we need to retrieve that directly from the source code IMO.
On Mon, 12 Sep 2005, Alexandre Julliard wrote:
Robert Shearman rob@codeweavers.com writes:
Wouldn't it be better to extend the spec format to allow for a longlong type instead?
I was wondering about that too.
I considered doing that, but I decided it would just add complexity for no real reason. If we really need more detailed parameter info then we need to retrieve that directly from the source code IMO.
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.
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...
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'?
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.
-
Alexandre Julliard -
Francois Gouget -
Robert Shearman