Re: [ECOS] No zlib crc32 support?

["Steve Strublic" <SStrublic at hypercom dot com>]

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