PE> Actually, that might not be true. For starters, the reference I
PE> used was a magazine article from "embedded systems programming"
PE> which Roy or Dieter (I think) sent me. Secondly, someone was
PE> quoting the X.25 specs, saying that the seed value should be
PE> 0xffff for the CCITT one. The X.?? specs were sufficiently
PE> vague that I couldn't be dead sure that was true (my own
PE> reference explicitly said that 0xffff seed was only for SDLC).

BL> Oh, no! All the SWAG 16-bit CRC use a zero seed. 

Which appears to be the consensus for everything except the CCITT one.

PE> Next, there was no mention of XORing the 32-bit CCITT result
PE> with 0xffffffff, but that's what Zmodem does, and that's what
PE> these people (in NET_DEV) were saying they thought was always
PE> the case.

BL> The idea is to get the bytes in the order they are sent by comms
BL> (they are sent backwards) without having to process them. Your 32-bit
BL> CRC gives the same answer as the 'zmodem' ones in SWAG, so I assumed
BL> you had it right. In fact, they are still backwards and need extra
BL> processing. 

My routines provide a crc32Byte1() etc routines.

BL> BTWTW... why do you rabbit on about unsigned longints in your
BL> code? All the operations are bitwise, so why does it matter?

PE> Bitwise operations on signed integers that have negative values
PE> in them are not guaranteed to do what you would like. Unsigned
PE> ones are. There are multiple ways of implementing signed
PE> integers (2's complement, sign-magnitude). 

BL> Within the one language??

It's actually machine.  And no, the hardware doesn't change in the midst of
running your program.

BL> Anyway, my point is what does it matter if you are only dealing with 
BL> a string of 32 bits. They can call it anything they like... right?

Well, on a signed-magnitude computer, the hardware manufacturers may have
provided a shift-right which preserves the sign, so that -16 shifted 1 bit
to the right becomes -8.  It may make a lot of sense. And if you don't want
that, use unsigned instead.

BFN.  Paul.
@EOT:

---