Date: Tue, 26 Apr 2005 14:28:39 -0700 From: Marcel Moolenaar <marcel@xcllnt.net> To: Jose M Rodriguez <josemi@freebsd.jazztel.es> Cc: freebsd-current@freebsd.org Subject: Re: rigth crc32 implementation Message-ID: <ca65daa6ade5e2e190ad653fc8906a3f@xcllnt.net> In-Reply-To: <200504262222.41463.josemi@redesjm.local> References: <200504261143.55195.josemi@redesjm.local> <20050426194208.GB7773@ns1.xcllnt.net> <200504262222.41463.josemi@redesjm.local>
next in thread | previous in thread | raw e-mail | index | archive | help
On Apr 26, 2005, at 1:22 PM, Jose M Rodriguez wrote: > El Martes, 26 de Abril de 2005 21:42, Marcel Moolenaar escribi=F3: >> On Tue, Apr 26, 2005 at 11:43:54AM +0200, Jose M Rodriguez wrote: >>> My first think was use the libkern based one, but I found: >>> sys/linkern/crc32.c >>> >>> - the code may not be endian safe. >> >> It operates on bytes, so it's endian-safe. Note that the uint32_t >> that's returned is not subject to endianness issues: it's always >> in the native byte order. The caller of crc32 needs to byteswap >> if it needs to compare this integral with a CRC that's not in >> the native byte order. >> > > Yes, but this code come from a previous reduction: calculate the table > from a xor/shift bit oriented alg. True, but doesn't that imply that the reduction is endian-independent? There's no big end and/or little end to a bit, so to speak. The values in the table are the result of mathematical calculations, which by definition do not depend on the endianness of the machine that was used to compute them. Yes, the in-memory representation of those values do differ but that's not the issue. Or am I missing something (possibly very obvious)? > Looking at sys/net/if_ethersubr.c ether_crc32_be() & ether_crc32_le(),=20= > I > became to doubt if we need two tables, with bitesex based #ifs. I think those are =042 different algorithms altogether. As far as I can tell, there's no need for it. A shift-right on a little-endian box yields the same effect as a shift-right on a big-endian box. It effectively divides the value by two. That you won't achieve if the shift-right moves the bits towards the most-significant bit, right? So why does one do a shift-right when the other does a shift-left? Why does one define the carry as the least-significant bit and the other as the most-significant bit? Again: math has never been my strongest ability, so it's possible that I simply have a mathematical cross-wire in my head preventing me from thinking mathematically clearly :-) --=20 Marcel Moolenaar USPA: A-39004 marcel@xcllnt.net
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?ca65daa6ade5e2e190ad653fc8906a3f>