williams@nssdcs.gsfc.nasa.gov (James W. Williams) (08/06/90)
From: James W. Williams <williams@nssdcs.gsfc.nasa.gov> I am implementing, for BSD 4.4, the POSIX cksum program as described in P1003.2/D10. This program uses table look-up to calculate a CRC "checksum" for each of its file arguments. This table consists of 256 hexadecimal constants and it would be extremely tedious and error-prone for me to type this in. If someone out there on the committee has this table on line and could mail it to me, I would be most grateful. So as not to waste net bandwidth, and clog my mailbox with multiple copies of the table, I suggest you just let me know that you have it, and I'll pick a random person to actually send it to me. While I have your attention, the section on this program, 4.9, is titled "cksum - Display file checksums and block counts". Given that this program, unlike the sum programs of BSD and system V, prints byte counts, not block counts, shouldn't the section title be "cksum - Display file checksums and byte counts"? Also, it is noted that this program is not backward compatible with either the BSD or system V versions of sum, thus it was given a new name. It is further noted that the term "checksum" is used for historical reasons, even though the algorithm given is not, technically, a checksum. This seems oddly inconsistent. Given that the name is changing, why not call it crcsum, or just crc? Thanks for your help and attention, Spoken: Jim Williams Domain: williams@nssdcs.gsfc.nasa.gov Phone: +1-301-555-1212 UUCP: uunet!mimsy!williams USPS: NASA/GSFC, Code 633, Greenbelt, MD 20771 Motto: There is no 'd' in "kluge"! It rhymes with "deluge", not "sludge". Volume-Number: Volume 21, Number 14
andrew@alice.uucp (Andrew Hume) (08/07/90)
From: andrew@alice.uucp (Andrew Hume) i would hate to cause trouble but can anyone justify why cksum uses anything other than CRC-32 for its polynomial? (i am not 1000% sure it isn't but am fairly sure.) it really frosts my shorts when CCITT and other folks bust their chops developing and testing 32 bit CRCs, find a really good one and then posix picks some hokey thing whose only apparent recommendation is that pathalias uses it (not strictly the highest form of praise). Volume-Number: Volume 21, Number 23
trt@rti.rti.org (Thomas Truscott) (08/10/90)
From: Thomas Truscott <trt@rti.rti.org> > i would hate to cause trouble but can anyone justify > why cksum uses anything other than CRC-32 for its polynomial? I critiqued the cksum manual page for Keith Bostic about a year ago, suggested they use CRC-32, and provided a general-purpose cksum program that could use any polynomial (CRC-32 by default). I thought it was nicely written and as fast as anything portable can be. I guess it got dropped on the floor. Tom Truscott Volume-Number: Volume 21, Number 26
randyc@hpfclj.hp.com (Randy Campbell) (08/15/90)
From: Randy Campbell <randyc@hpfclj.hp.com> >From: andrew@alice.uucp (Andrew Hume) > > i would hate to cause trouble but can anyone justify >why cksum uses anything other than CRC-32 for its polynomial? >(i am not 1000% sure it isn't but am fairly sure.) >it really frosts my shorts when CCITT and other folks >bust their chops developing and testing 32 bit CRCs, find a really good >one and then posix picks some hokey thing whose only apparent recommendation >is that pathalias uses it (not strictly the highest form of praise). > > >Volume-Number: Volume 21, Number 23 >---------- Well, I had some part in developing the current (Draft 10) spec of cksum. There was certainly no intention to "frost your shorts" (is this a reference to some kind of stone-washed jeans?). The Draft 9 spec for cksum (the one that was derived from pathalias) had a problem in that it would too often yield identical results for files that were different only near the beginning. It may be that CRC-32 would be an adequate or even superior polynomial to the one we used. However, the polynomial selected is the one used by Ethernet and is specified in a networking standard (ISO 8802-3), so we thought it would be appropriate to use. In fact, finding a known, standard polynomial to use was one of our criteria. And it gave good empirical results on some filesets that had exposed weaknesses in other implementations. Randy Campbell Volume-Number: Volume 21, Number 31