From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 10306 invoked by alias); 10 Dec 2003 08:39:01 -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 10295 invoked from network); 10 Dec 2003 08:38:59 -0000 Received: from unknown (HELO londo.lunn.ch) (80.238.139.98) by sources.redhat.com with SMTP; 10 Dec 2003 08:38:59 -0000 Received: from lunn by londo.lunn.ch with local (Exim 3.36 #1 (Debian)) id 1ATzrZ-0005t5-00; Wed, 10 Dec 2003 09:38:29 +0100 Date: Wed, 10 Dec 2003 08:39:00 -0000 To: Steve Strublic Cc: ecos-discuss@sources.redhat.com Message-ID: <20031210083829.GN2527@lunn.ch> Mail-Followup-To: Steve Strublic , 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/msg00113.txt.bz2 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