[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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
>> 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



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

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

Reply to: