gnunet-developers
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [GNUnet-developers] big endian & CRC problems


From: Christian Grothoff
Subject: Re: [GNUnet-developers] big endian & CRC problems
Date: Thu, 23 Dec 2004 06:08:59 +0100
User-agent: KMail/1.5.4

On Montag, 20. Dezember 2004 14:04, Jussi Eloranta wrote:
> Howdy,
>
> Long time ago I reported that the MacOS X (PPC / big endian) machines
> were complaining about CRC errors when downloading files. The files
> actually download correctly with no problmes. For example, with GNUnet
> 0.6.5 I get:
>
> Dec 19 18:58:15 FAILURE: File corrupted (or bug).
> Dec 19 18:58:15 Assertion failed at block.c:1855.
>
> or with insert;
>
> Dec 19 21:30:47 FAILURE: File corrupted (or bug).
> Dec 19 21:30:47 Failure at block.c:1838.
>
> If I look at function childDownloadCompleted in block.c I understand
> that it
> calculates CRC checksum for the data as well as for the CRCs obtained
> from the data?
> The latter is in parent->crcs[] array which have elements of type int.
> Now, if
> one calculates CRC of this array then it will very much depend on the
> byte
> ordering of each int. Or am I missing something ?

No, you're perfectly right, that's an oversight that was not done properly 
when we did the endianess conversion.  Now, in 0.7.0 I'm getting rid of the 
CRCs completely, so there's actually nothing left to fix there.  For the 
GNUnet06 branch, I would suggest that until then we define these fields as 
little-endian and convert to/from that on big-endian machines, which should 
avoid breaking compatibility for most existing files (that is, those created 
on little-endian machines).

> Anyway, it is the following test that fails:
>
> crc32N(&parent->crcs[0], sizeof(int) * parent->childcount) !=
> parent->crc32
>
> in block.c.
>
> ----------
>
> Another thing. In util/checksum.c the static array crc_table element
> 255 is used to
> check if the crc array needs to be generated. Should the compiler
> initialize these
> to zero??? If not the one should have another variable, like
> crc_table_initialized = 0
> which would be used as an indicator.

No, all statics that are not explicitly initialized in C always default to 0.  
So an explicit initializer is not required.

Cheers

Christian





reply via email to

[Prev in Thread] Current Thread [Next in Thread]