From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 10118 invoked by alias); 10 Dec 2003 16:14:13 -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 10111 invoked from network); 10 Dec 2003 16:14:12 -0000 Received: from unknown (HELO thing2.hypercom.com) (208.248.82.254) by sources.redhat.com with SMTP; 10 Dec 2003 16:14:12 -0000 Received: from Azphxn01.hypercom.com (azphxn01.hypercom.com [10.0.2.70]) by thing2.hypercom.com (8.12.7/8.12.7) with ESMTP id hBAGDWpO011253; Wed, 10 Dec 2003 09:13:52 -0700 (MST) To: andrew@lunn.ch Cc: ecos-discuss@sources.redhat.com Message-ID: From: "Steve Strublic" Date: Wed, 10 Dec 2003 16:14:00 -0000 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Subject: Re: [ECOS] No zlib crc32 support? X-SW-Source: 2003-12/txt/msg00127.txt.bz2 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. 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. 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. Steve -------- "Space is almost infinite. In fact, we think it is infinite." -- Dan Quayle andrew@lunn.ch To: SStrublic@hypercom.com 12/10/03 01:38 AM cc: ecos-discuss@sources.redhat.com Subject: Re: [ECOS] No zlib crc32 support? On Tue, Dec 09, 2003 at 02:04:05PM -0700, Steve Strublic wrote: > Would there be any objection to including it (meaning the 'official' > zlib version of crc32) in the zlib package anyhow? In my case (and > I would think many others), it makes what I'm doing completely > portable between Linux and eCos without having to ifdef for eCos. I took this and several other crc32 implementations out from various bits of eCos simply because an image would end up with many implementations in the same image. This is particularly bad because each one had its own table of coefficients which is quite large and totally redundant. eCos wants to be small so this was an obvious optimization. There was also the name space pollution problem. 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. So sorting this mess out i decide it was better to stick to the standard cyg_ prefix convention. I would be reluctant to put back the crc32 function in zlib. Its a step back towards chaos, bigger images and potential naming problems. Either do as Gary suggested, or call cyg_crc32(). 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