tcopy produces negative output ...
2007-12-25 10:34:00
------------------
Hi Sun-Managers,
tcopy /dev/rstx
gives the following output :
file 1: records 1 to 279729: size 10240
file 1: eof after 279729 records: -1430542336 bytes
eot
total length: -1430542336 bytes
How should I interpret the "total length" - as 1.4GB
or as an erroneous output?
Regards,
Pravin
----------------------
Thanks to:
---------
keener@upenn5.hep.upenn.edu (Paul T. Keener)
Derek Terveer <derek.terveer@ci.saint-paul.mn.us>
Igor Schein <igor@txc.com>
"K.Ravi" <RAVKRISH.IN.ORACLE.COM.ofcmail@in.oracle.com>
Jochen Bern <bern@penthesilea.uni-trier.de>
"Carsten B. Knudsen" <cbk@terma.dk>
-----------------------
The answer:
I would like to quote Jochen Bern's reply which was
more detailed:
1. As an Overflow. Your tcopy uses some Kind of Variable Type internally
which
-- should better be some Kind of Integer Number, rather than a Real ;-)
-- uses one Bit as a Sign (rather than using unsigned Integers)
Conclusion: It consists of n Bits (n a Multiple of 8) and, thus, can
represent positive Numbers from 1 (Bits 0...01) through
(2^(n-1))-1 (Bits 01...1) and negative Numbers from -1 (Bits 1...1)
through -(2^(n-1)) (Bits 10...0). (The Sign Bit is always the left-
most one.) As you see, when the Bits go from 01...1 to 10...0 (the
"Increase by 1" that actually does the Overflow), the Number
represented changes from (2^(n-1))-1 (MAX-1) to -(2^(n-1))
(-MAX), i.e., by (- 2 MAX + 1) instead of +1. Thus, every Over-
flow needs to be corrected by adding 2 MAX.
Assuming that you had only ONE Overflow, your tcopy likely uses
n = 4*8 = 32 (normal int/long on sun4 Architectures), hence
MAX = 2147483648 (2 Gig) and corrected Value approximately
- 1.4 GB + 2*2 GB = 2.6 GB.
2. As a Hint that you need a better tcopy. ;-) Isn't there a GNU Version?
------------------------------
Comments
Got something to say?
You must be logged in to post a comment.
