12 Dec
2015
12 Dec
'15
1:22 a.m.
From: Random832
Interestingly, the SysIII sum.c program, which I
assume yields the same
result for this input, appears to go through the whole input
accumulating the sum of all the bytes into a long, then adds the two
halves of the long at the end rather than after every byte.
That's the same hack a lot of TCP/IP checksums routines used on machines with
longer words; add the words, then fold the result in the shorter length at the
end. The one I wrote for the 68K back in '84 did that.
This suggests that the two programs would give
different results for
very large files that overflow a 32-bit value.
No, I don't think so, depending on the exact detals of the implementation. As
long as when folding the two halves together, you add any carry into the sum,
you get the same result as doing it into a 16-bit sum. (If my memory of how
this all works is correct - the neurons aren't what they used to be,
especially late in the day... :-)
Also, if this sign extends, then its behavior on
"negative" (high bit
set) bytes is likely to be very different from the SysIII one, which
uses getc.
I have this bit set that in C, 'char' is defined to be signed, and
furthermore that when you assign a shorter int to a longer one, the sign is
extended. So if one has a char holding '0200' octal (i.e. -128), assigning it
to a 16-bit int should result in the latter holding '0177600' (i.e. still
-128). So in fact I think they probably act the same.
Noel
12 Dec
12 Dec
1:46 a.m.
New subject: why is sum reporting different checksum's between v6 and v7
Noel Chiappa writes:
No, I don't think so, depending on the exact
detals of the implementation. As
long as when folding the two halves together, you add any carry into the sum,
you get the same result as doing it into a 16-bit sum.
The issue I was suggesting comes if you've lost carry bits
_before_ folding the two halves together, when you were working
in 32-bit arithmetic.
(If my memory of how
this all works is correct - the neurons aren't what they used to be,
especially late in the day... :-)
The SysIII sum.c file uses getc and stores the result in an int,
not a char.
I *think* the definition of getc returns positive values the
same as modern systems do, despite the manpage's caution to
check feof because EOF is a "valid integer value":
#define getc(p) (--(p)->_cnt>=0? *(p)->_ptr++&0377:_filbuf(p))
_filbuf also has & 0377 in the relevant place.
If getc returns negative values for high-bit characters, on the
other hand, then they would sign-extend to 32 bits when the long
math is done, still yielding different results.
Also, if this sign extends, then its behavior on
"negative" (high bit
set) bytes is likely to be very different from the SysIII one, which
uses getc.
I have this bit set that in C, 'char' is defined to be signed 
1:50 a.m.
New subject: why is sum reporting different checksum's between v6 and v7
Noel Chiappa scripsit:
I have this bit set that in C, 'char' is
defined to be signed,
If you mean in PDP-11 C, you're right, char is signed precisely because
MOVB sign extends. In C in general, char's signedness is undefined.
Similarly the signedness of a bitfield is undefined, which means that
the portable range of a 1-bit field is just 0, though there is another
value that might be +1 or -1.
--
John Cowan http://www.ccil.org/~cowan cowan(a)ccil.org
Eric Raymond is the Margaret Mead of the Open Source movement.
--Bruce Perens, a long time ago
3056
days inactive
3056
days old
2 comments
3 participants
participants (3)
-
jnc＠mercury.lcs.mit.edu -
John Cowan -
Random832