[Top][All Lists]
[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