From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 8230 invoked by alias); 11 Dec 2003 00:38:29 -0000 Mailing-List: contact ecos-discuss-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: ecos-discuss-owner@sources.redhat.com Received: (qmail 8221 invoked from network); 11 Dec 2003 00:38:27 -0000 Received: from unknown (HELO londo.lunn.ch) (80.238.139.98) by sources.redhat.com with SMTP; 11 Dec 2003 00:38:27 -0000 Received: from lunn by londo.lunn.ch with local (Exim 3.36 #1 (Debian)) id 1AUEqU-0007EK-00; Thu, 11 Dec 2003 01:38:22 +0100 Date: Thu, 11 Dec 2003 00:38:00 -0000 To: Steve Strublic Cc: andrew@lunn.ch, ecos-discuss@sources.redhat.com Message-ID: <20031211003822.GC3680@lunn.ch> Mail-Followup-To: Steve Strublic , andrew@lunn.ch, ecos-discuss@sources.redhat.com References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.4i From: Andrew Lunn Subject: Re: [ECOS] No zlib crc32 support? X-SW-Source: 2003-12/txt/msg00142.txt.bz2 On Wed, Dec 10, 2003 at 09:09:53AM -0700, Steve Strublic wrote: > > Andrew, > >> "One of the crc32()functions actually implemented a different >> variation on the crc32() algorithm which was incompatible with all >> the other crc32 algorithms. Plus some "user" code may want to yet >> again implement its own crc32 algorithm." > This concerns me as a developer. I would hope that there would be > one supported CRC-32 algorithm; the one that is commonly accepted by > the general community, the one provided by zlib. It sounds like > what you're saying is that cyg_crc32() is to be that single > algorithm. There appears to be no commenly accepted crc32 algorithm. Instead there are at least two that i know off. There is cyg_crc32 which is what zlib uses and is also the same crc that Ethernet frames uses and probably other protocols. There is another well known one, cyg_posix_crc32 which is what the POSIX standards have specified. This is used by programs like cksum. There are other 32 bit algorithms, such as Adler, but i don't think this is actually a Cyclic Redundancy Check but some other algorithm. There are no standardized function names for these algorithms. 802.3 just specifies the algorithm, not its name. POSIX is the same as far as i know. > I have a setup where I generate binaries on a Linux machine. These > binaries are compressed/encrypted and then the output run through > CRC-32, and uploaded to the platform running eCos. The platform > then validates the encrypted binary by generating a CRC-32 value. > Obviously, the values must match. This is where my concern over > cyg_crc32() comes from. What you should really do if first specify what algorithm you want to use. This could be the ethernet CRC, POSIX CRC , hmac or anything else. Then find an implementation on both platforms. Doing it this way around guarantees it will work. Assuming a none standardized function name works the same on different platforms is dangerous. > As long as eCosCentric will guarantee that the output from > cyg_crc32() is and will remain 100% compatible with zlib's crc32(), > that works for me. The maintainers have no intention of changing these functions unless somebody can prove they are broken, which i think it very unlikely. Andrew -- Before posting, please read the FAQ: http://sources.redhat.com/fom/ecos and search the list archive: http://sources.redhat.com/ml/ecos-discuss