I've got a version in the works with tests in tests/test-csum.c. Previously I misunderstood the way that the checksum works. I now understand that the constants are in host-byte order, and the result of the computation provides a checksum in the mirrored byte order. This means the calculation will be wrong on big-endian systems (in this case, value is le32, we return be32). There are a couple of further steps missed out for correct calculation in this patch. I'll work on fixing these.
I'm not sure why my sparse didn't pick this up, I've been using "make C=1", and the only sparse error I see (for a lot of files) is "/usr/include/bits/wchar.h:37:8: error: garbage at end: '\0' - 1 > 0". I'm using Debian Squeeze to build (sparse is version 0.4.1 or so). Any thoughts? On Thu, Dec 27, 2012 at 12:35 PM, Ben Pfaff <[email protected]> wrote: > > On Wed, Dec 26, 2012 at 03:23:39PM -0800, Ben Pfaff wrote: > > On Tue, Dec 18, 2012 at 11:00:38PM +1300, Joe Stringer wrote: > > > This implementation was derived from FreeBSD: > > > http://code.google.com/p/freebsd-head/source/browse/sys/libkern/crc32.c > > > > > > Signed-off-by: Joe Stringer <[email protected]> > > > > Would you mind adding a test? tests/test-csum.c is a reasonable place > > to put it. > > Also, sparse has several complaints about crc32c.c of the form: > > ../lib/crc32c.c:70:18: warning: incorrect type in initializer (different base > types) > ../lib/crc32c.c:70:18: expected restricted __be32 > ../lib/crc32c.c:70:18: got unsigned long > > and I think I agree with it: those constants are in host byte order, > not network byte order. Something is odd here. > > Thanks, > > Ben. _______________________________________________ dev mailing list [email protected] http://openvswitch.org/mailman/listinfo/dev
