[openib-general] [PATCH 1/3 v2] osm: Changes for windows compatability

[Yevgeny Kliteynik]

Sasha Khapyorsky wrote:
> On 17:46 Wed 27 Dec     , Yevgeny Kliteynik wrote:
>> Hi Hal.
>>
>> Fixing windows compilation problems
>> [V2 - Previous patch had an error]
>>
>> Signed-off-by: Yevgeny Kliteynik <kliteyn at dev.mellanox.co.il>
>> ---
>>  osm/include/iba/ib_types.h |    2 ++
>>  1 files changed, 2 insertions(+), 0 deletions(-)
>>
>> diff --git a/osm/include/iba/ib_types.h b/osm/include/iba/ib_types.h
>> index 723e8b9..ec65b64 100644
>> --- a/osm/include/iba/ib_types.h
>> +++ b/osm/include/iba/ib_types.h
>> @@ -59,9 +59,10 @@ BEGIN_C_DECLS
>>           #define OSM_EXPORT	__declspec(dllimport)
>>      #endif
>>      #define OSM_API __stdcall
>> +    #define OSM_CDECL __cdecl
>>  #else
>>      #define OSM_EXPORT	extern
>>      #define OSM_API
>> +    #define OSM_CDECL
>>      #define __ptr64
>>  #endif
> 
> Just wondering, how does lack of __cdecl hurt windows compilation (in
> the context of where those __cdecl is used)?
> What is the reason to have both __stdcall and __cdecl (and what is the
> default)?

Hi Sasha.

The __cdecl is default on windows. However, the compiler complained
about a certain function (more specifically - about a comparison function that
is supplied as an argument to qsort() function) that it's defined as __stdcall 
instead of __cdecl. As MST has pointed out, it's probably because of compilation 
flag.

I'll check with the windows guys why do we have such compilation flag (assuming we 
do have it), and whether it can be removed. Same goes for the __stdcall - I'm sure
there is some historical reason for having it. The question is - do we still need it.

Thanks.

-- Yevgeny
 
> Sasha
>