Re: udhcp patches/ endianess

Russ Dill <Russ.Dill <at> asu.edu> writes:
>> So unless I am very much mistaken, this is correct for both
>> cases.
>
> Why not keep the known, working crc algorithm?

<nitpicking>
This isn't a CRC algorithm.
</>

> Its not as if the code is doing the calculation very often and on
> very much data.

If you have cycles to waste, what keeps you from using the 'known to be
working' code, which is known to be working, because it's copied out
of UNIX Network Programming, with RWS having copied it out of a
'public domain' ping program? Nothing. Maybe one day gcc will come
down on you badly because of the undefined and implementation
defined constructs used in the code, but this, too, is entirely your
problem. It certainly won't be mine, because I don't feel inclined to
add more compiler versions to the zoo I am already maintaining on my
machine to accomodate various other 'known to be working' pieces of
legacy code.

And there is the additional issue that someone might be tempted to use
the code to calculate IP checksum for other types of datagrams, which
will work nicely as long as the sum does not exceed the value 2^31,
thereby affecting the sign bit of the int32_t and turning the 'fold'
loop into an endless loop, which is an effect that I would rather
prevent than fix (and people will mindlessly copy to code out of