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. >> > Attached is a trivial patch (partly from Daniele Di Proietto) that >> > addresses some of the cases; however, some of them could be >> > fixed in different ways. >> > >> > In particular, vport_priv() and vport_from_priv() should be >> > changed to return a const pointer, but this has a bit of >> > an avalanche effect on the code and I am not sure if you are >> > willing to go for it. >> >> I'm not sure that it's even possible to change those functions to >> return a const pointer - it's private space so vport implementations >> are allowed to write into it. > > i see. So the const qualifier in the argument to those functions > is ignored/overridden intentionally ? Well really we have two types of functions here: one that accepts a const and returns a const and one that is the same but for non-const pointers. Every use should be able to map directly to one of those two without the need to do any casting away of constness but in practice they've been combined into a single function here. _______________________________________________ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
