Re: mode_t bitwise operations different under kFreeBSD?

[Nikolaus Rath <Nikolaus@rath.org>]

Petr Salinger <Petr.Salinger@seznam.cz> writes:
>>> It is roughly equal to this:
>>>
>>> void foo(unsigned short int a)
>>> {
>>>    a = (( a & (~0x1F)) | 0x10);
>>> }
>>
>> It seems to me that the S_* constants should have the same type as mode_t, so it's not quite the same...
>
> The "~S_IFMT" is not a constant.
>
> See also 6.3.1 in ISO/IEC 9899 - Programming languages - C, namely "integer promotions".
>
>>> This code will warn also under Linux.
>>
>> Do you mean the fragment above or the original code? Because the original code produces problems only on kFreeBSD, see https://buildd.debian.org/status/package.php?p=python-llfuse
>
> The fragment above, because
>
> Linux:    mode_t is unsigned int
> FreeBSD:  mode_t is short unsigned int
>
> Again please see "unsigned short" x "signed int".
>
> Or also try to compile with "-Wconversion -Werror" just
> **
> unsigned short a = ~0x1F;
> **

I really appreciate your efforts to help me, but I'm afraid I just don't
follow. Could you possibly explain this on a lower level?

I have some knowledge of the C type system, but I don't understand what
you mean with "please see "unsigned short" x "signed int"."

I assumed that by using mode_t and preprocessor macros, I am working
relatively portable so that I don't have to worry if mode_t is
implemented as unsigned short or signed int.

Could you maybe just tell me how the code should look like to work on
both Linux and BSD? Hardcoding a numeric literal really doesn't seem
like the proper solution to me...


Thanks!

   -Nikolaus

-- 
 »Time flies like an arrow, fruit flies like a Banana.«

  PGP fingerprint: 5B93 61F8 4EA2 E279 ABF6  02CF A9AD B7F8 AE4E 425C