Re: [ECOS] No zlib crc32 support?

[Andrew Lunn <andrew@lunn.ch>]

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