Re: [ECOS] No zlib crc32 support?

["Steve Strublic" <SStrublic@hypercom.com>]

Gary/Andrew,

Works for me!  Thanks for the info.  I'll use cyg_crc32() as recommended.

Steve

--------
"Space is almost infinite.  In fact, we think it is infinite."  -- Dan Quayle



                                                                                                                                                       
                      gary@mlbassoc.com                                                                                                                
                                               To:       SStrublic@hypercom.com                                                                        
                      12/10/03 09:20 AM        cc:       andrew@lunn.ch, ecos-discuss@sources.redhat.com                                               
                                               Subject:  Re: [ECOS] No zlib crc32 support?                                                             
                                                                                                                                                       




On Wed, 2003-12-10 at 09:09, 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.
>
> 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.
>

It's actually not up to eCosCentric, but rather the eCos maintainers :-)

In any case, we would never [intentionally] use a version which was not
compatible with the ZLIB version.  The main reason for having it in the
separate CRC package, as Andrew pointed out, is so that there need only
be one copy in your application, whether you use ZLIB or just RedBoot or
whatever.

> 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
>
--
Gary Thomas <gary@mlbassoc.com>
MLB Associates






-- 
Before posting, please read the FAQ: http://sources.redhat.com/fom/ecos
and search the list archive: http://sources.redhat.com/ml/ecos-discuss