This is the mail archive of the ecos-discuss@sources.redhat.com mailing list for the eCos project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: No zlib crc32 support?


Andrew, that's why I chose zlib's crc32 algorithm.

On a technical note, I compared the output from crc32() from Linux's zlib with the output from the
corresponding function in eCos, cyg_crc32_accumulate()...  and they don't match.  I did take into
account the endian change from Linux on Intel versus eCos on PowerPC.

I inspected the code for both implementations, and found that eCos's cyg_ether_crc32_accumulate() is
the implementation that matches crc32() in zlib.  The output from cyg_ether_crc32_accumulate()
matches the output from zlib's crc32() under Linux after accounting for the endian change.

Taking the crc32() implementation from zlib and including it in eCos... the output matches, of
course.  This is why I was initially concerned about not having crc32() as part of zlib in eCos.

Andrew, you state... "The maintainers have no intention of changing these functions unless somebody
can prove they are broken, which i think it very unlikely."

I think I may have just proved that there's an issue.  I don't think it's proper to have to #define
'crc32' as' cyg_ether_crc32_accumulate'.  I'd prefer to hear the maintainers' position firsthand.

Steve

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



                                                                                                                                                                
                      andrew@lunn.ch                                                                                                                            
                      Sent by:                          To:       SStrublic@hypercom.com                                                                        
                      ecos-discuss-owner@sources        cc:       andrew@lunn.ch, ecos-discuss@sources.redhat.com                                               
                      .redhat.com                       Subject:  Re: [ECOS] No zlib crc32 support?                                                             
                                                                                                                                                                
                                                                                                                                                                
                      12/10/03 05:38 PM                                                                                                                         
                                                                                                                                                                
                                                                                                                                                                




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






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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]