Re: mode_t bitwise operations different under kFreeBSD?
On 07/16/2011 02:45 PM, Petr Salinger wrote:
>>
>> gcc -pthread -fno-strict-aliasing -DNDEBUG -g -fwrapv -O2 -Wall
>> -Wstrict-prototypes -g -O2 -fPIC -g -I/usr/include/python2.7 -c
>> src/llfuse.c -o
>> build/temp.gnukfreebsd-8.1-1-686-smp-i686-2.7/src/llfuse.o
>> -D_FILE_OFFSET_BITS=64 -I/usr/include/fuse -DFUSE_USE_VERSION=28
>> -DLLFUSE_VERSION="0.33" -Werror -Wall -Wextra -Wconversion
>> -Wno-unused-parameter -Wno-sign-conversion
>> -Wno-unused-but-set-variable -fno-strict-aliasing
>> src/llfuse.c: In function '__pyx_f_6llfuse_fuse_mkdir':
>> src/llfuse.c:4693:50: error: conversion to 'mode_t' from 'int' may
>> alter its value [-Werror=conversion]
>>
>> Now, llfuse.c is itself code generated by Cython, so it's hard to read.
>> However, the assignment that gcc complains about is just this:
>>
>> static void __pyx_f_6llfuse_fuse_mkdir(fuse_req_t __pyx_v_req,
>> fuse_ino_t __pyx_v_parent, const char *__pyx_v_name, mode_t
>> __pyx_v_mode) {
>> [....]
>> __pyx_v_mode = ((__pyx_v_mode & (~S_IFMT)) | S_IFDIR);
>>
>>
>> i.e., I'm making sure that the type bits of a mode_t variable are set to
>> S_IFDIR.
>>
>> Why does this require a conversion in kFreeBSD?
>
> 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...
> 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
Best,
-Nikolaus
--
»Time flies like an arrow, fruit flies like a Banana.«
PGP fingerprint: 5B93 61F8 4EA2 E279 ABF6 02CF A9AD B7F8 AE4E 425C
Reply to: