Thanks George,
I will definitely try that !
back to the initial question, has someone any thoughts on which bit(s) we
can lose when using cutoff ?
Cheers,
Gilles
On Saturday, February 6, 2016, George Bosilca <bosi...@icl.utk.edu> wrote:
> In addition shouldn't we use uintptr_t instead of the intptr_t to cope
> with the MSB during the shifting operations?
>
> George
> On Feb 5, 2016 10:08 AM, "Jeff Squyres (jsquyres)" <jsquy...@cisco.com
> <javascript:_e(%7B%7D,'cvml','jsquy...@cisco.com');>> wrote:
>
>> On Feb 5, 2016, at 9:26 AM, Gilles Gouaillardet <
>> gilles.gouaillar...@gmail.com
>> <javascript:_e(%7B%7D,'cvml','gilles.gouaillar...@gmail.com');>> wrote:
>> >
>> > static inline opal_process_name_t ompi_proc_sentinel_to_name (intptr_t
>> sentinel)
>> > {
>> > sentinel >>= 1;
>> > sentinel &= 0x7FFFFFFFFFFFFFFF;
>> > return *((opal_process_name_t *) &sentinel);
>> > }
>>
>> I don't have much of an opinion on any of the other stuff here, but I
>> note that this is unsafe. I know we don't really care about non-64 bit
>> these days, but we shouldn't be knowingly breaking it. Instead of ANDing
>> with a fixed constant, shouldn't it be something like:
>>
>> intptr_t mask = ~1 >> 1;
>> sentinel &= mask;
>>
>> --
>> Jeff Squyres
>> jsquy...@cisco.com <javascript:_e(%7B%7D,'cvml','jsquy...@cisco.com');>
>> For corporate legal information go to:
>> http://www.cisco.com/web/about/doing_business/legal/cri/
>>
>> _______________________________________________
>> devel mailing list
>> de...@open-mpi.org <javascript:_e(%7B%7D,'cvml','de...@open-mpi.org');>
>> Subscription: http://www.open-mpi.org/mailman/listinfo.cgi/devel
>> Link to this post:
>> http://www.open-mpi.org/community/lists/devel/2016/02/18557.php
>>
>
