On Tue, Jan 21, 2014 at 9:54 AM, Jesse Gross <je...@nicira.com> wrote:
> On Wed, Jan 15, 2014 at 3:46 PM, Luigi Rizzo <ri...@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 <ri...@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. cheers luigi
_______________________________________________ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
