Re: type mismatch on cpuset.h

[Mark Geisert <mark@maxrnd.com>]

[Redirected here from the main mailing list...]

Hi Corinna,

Corinna Vinschen via Cygwin wrote:
> Hi Mark,
> 
> On Mar  6 07:57, Marco Atzeri via Cygwin wrote:
>> Hi,
>>
>> building latest gdal I noticed a type mismatch, that forced me to build
>> with "-fpermissive"
>>
>> on /usr/include/sys/cpuset.h
>>
>>   #define CPU_ALLOC(num)      __builtin_malloc (CPU_ALLOC_SIZE(num))
>>
>>
>> but on
>> https://linux.die.net/man/3/cpu_alloc
>>
>>   cpu_set_t *CPU_ALLOC(int num_cpus)
>>
>>
>> so void* versus cpu_set_t*
> 
> Marco is correct.  cpuset.h was your pet project a while back.  Would
> you like to pick it up?  Maybe we should convert all the macros into
> type-safe inline functions, or macros calling type-safe (inline)
> functions, as on Linux as well as on BSD?

As far as I can tell from online docs, the CPU_SET(3) macros are still macros on 
Linux, though they are documented with prototypes as if they were functions.  I 
don't immediately see a need to change our cpuset.h for this.

I'm also uncertain what exactly you mean by "type-safe" in this context.  Could 
you please give me an example for one of the macros?

I desk-checked all the macros vs their prototypes and I believe CPU_ALLOC that 
Marco ran into is the only faulty one.  It could be fixed with a cast.  CPU_FREE's 
result is void so I should make sure __builtin_free() corresponds. 
CPU_ALLOC_SIZE's result is size_t and I believe the macro is correct as-is because 
it is an expression using untyped integers and sizeof()s, the latter are 
size_t-returning.

The other few macros that return results return int, and those are precisely the 
ones whose inline code uses an int variable to accumulate a result.

If there is some other consideration I'm not seeing, e.g. readability, please let 
me know.  Otherwise I don't really see a need for changes here (modulo casting 
return values properly where needed).

..mark