Brice Goglin, le Tue 13 Mar 2012 17:10:45 +0100, a écrit :
> Le 13/03/2012 17:04, Hartmut Kaiser a écrit :
> >>> But the problems I was seeing were not MSVC specific. It's a
> >>> proliferation of arcane (non-POSIX) function use (like strcasecmp,
> >>> etc.) missing use of HAVE_UNISTD_H, HAVE_STRINGS_H to wrap
> >>> non-standard headers, unsafe mixing of
> >>> int32<->int64 data types, reliance on int (and other types) having a
> >>> certain bit-size, totally unsafe shift operations, wide use of
> >>> (non-C-standard) gcc extensions, etc. Should I go on?
> > More investigation shows that the code currently assumes group (and
> > processor) masks to be 32 bit, which is not true on 64 bit systems.
> No. What it assumes is that you have a sane compiler where ulong is not
> 32bits on 64bits systems :)
Nothing says that an ulong is 64bit on a 64bit system. Only intptr_t can
be assumed to be 64bit. That's why we have HWLOC_BITS_PER_LONG actually.
In my memory I took care in the windows case that longs are 32bit, and
used DWORD for ulong. But since I had no test machine, I couldn't
promise it was working :)