[ovs-dev] const attributes for some kernel ovs functions ?

Jesse Gross jesse at nicira.com
Wed Jan 22 17:34:23 UTC 2014


On Tue, Jan 21, 2014 at 11:19 AM, Luigi Rizzo <rizzo at iet.unipi.it> wrote:
>
>
>
> On Tue, Jan 21, 2014 at 9:54 AM, Jesse Gross <jesse at nicira.com> wrote:
>>
>> On Wed, Jan 15, 2014 at 3:46 PM, Luigi Rizzo <rizzo at iet.unipi.it> wrote:
>> > On Wed, Jan 15, 2014 at 03:10:35PM -0800, Jesse Gross wrote:
>> >> On Sat, Jan 11, 2014 at 4:33 PM, Luigi Rizzo <rizzo at iet.unipi.it>
>> >> wrote:
>> >> > Hi,
>> >> > in porting the ovs kernel code to the FreeBSD kernel,
>> >> > compiling with -Wcast-qual -Werror gives some
>> >> >
>> >> >    warning: cast discards qualifiers from pointer target type
>> >> >
>> >> > due to 'const' being ignored. Another couple of warnings
>> >> > are on arguments to format strings.
>> >>
>> >> What are the warnings from the format strings? (and I guess, more
>> >> specifically, what is the definition of u64 if it is not unsigned long
>> >> long?)
>> >
>> > Oh i see. We used 'typedef uint64_t u64;' which seemed more appropriate
>> > than unsigned long long (which can be larger than 64), but of course
>> > what matters are established standards.
>> > We can move to unsigned long long and close this
>> > (though even the linux kernel has instances of all kinds):
>> >
>> >         $ grep -r ' u64;' linux-3.11.0/ | grep typedef
>> >
>> > linux-3.11.0/arch/powerpc/platforms/cell/spufs/spu_save.c:typedef unsigned
>> > long long u64;
>> >
>> > linux-3.11.0/arch/powerpc/platforms/cell/spufs/spu_restore.c:typedef
>> > unsigned long long u64;
>> >         linux-3.11.0/tools/lguest/lguest.c:typedef unsigned long long
>> > u64;
>> >         linux-3.11.0/tools/virtio/linux/types.h:typedef uint64_t u64;
>> >         linux-3.11.0/tools/testing/selftests/vm/hugetlbfstest.c:typedef
>> > unsigned long long u64;
>> >         linux-3.11.0/tools/perf/util/types.h:typedef uint64_t      u64;
>> >         linux-3.11.0/Documentation/ia64/err_inject.txt:typedef unsigned
>> > long u64;
>> >         linux-3.11.0/include/linux/raid/pq.h:typedef uint64_t u64;
>> >         linux-3.11.0/include/asm-generic/int-l64.h:typedef unsigned long
>> > u64;
>> >         linux-3.11.0/include/asm-generic/int-ll64.h:typedef unsigned
>> > long long u64;
>>
>> I think the last two are the ones that are included generically in the
>> kernel, the others are various random bits of code. So I while I would
>> agree that uint64_t is a more exact mapping, unsigned long long seems
>> to be the Linux standard.
>>
>
> we are in nitpicking land here, but note how the last two
> files define u64 differently, and also there does not seem
> to be a single standard across the board.
> The two headers in fact say it clearly:
>
> /*
>  * asm-generic/int-l64.h
>  *
>  * Integer declarations for architectures which use "long"
>  * for 64-bit types.
>  */
> #ifndef _ASM_GENERIC_INT_L64_H
> #define _ASM_GENERIC_INT_L64_H
>
> #include <uapi/asm-generic/int-l64.h>
>
>
> #ifndef __ASSEMBLY__
>
> typedef signed char s8;
> typedef unsigned char u8;
>
> typedef signed short s16;
> typedef unsigned short u16;
>
> typedef signed int s32;
> typedef unsigned int u32;
>
> typedef signed long s64;
> typedef unsigned long u64;
> ...
>
>
>
> and
>
>
> /*
>  * asm-generic/int-ll64.h
>  *
>  * Integer declarations for architectures which use "long long"
>  * for 64-bit types.
>  */
> #ifndef _ASM_GENERIC_INT_LL64_H
> #define _ASM_GENERIC_INT_LL64_H
>
> #include <uapi/asm-generic/int-ll64.h>
>
>
> #ifndef __ASSEMBLY__
>
> typedef signed char s8;
> typedef unsigned char u8;
>
> typedef signed short s16;
> typedef unsigned short u16;
>
> typedef signed int s32;
> typedef unsigned int u32;
>
> typedef signed long long s64;
> typedef unsigned long long u64;
> ...
>
>
> In other word, using %llx as a format for u64 is bound to
> create a problem somewhere.

OK, I see. I guess a cast is fine to avoid these warnings.



More information about the dev mailing list