I have a simple question about binary i/o. When I write to a file with element-type define as unsigned-byte 7(see code below) it produces a binary file that I can write and read back with no problems and that's great...I really like this feature. Now the question, when I enter the values 1,2,3,4,5,6,7,8.9,0 into the binary file – myfile it contains the values:
0A 00 00 00 01 C1 80 50 30 1C 10 09 00
Why does CLisp pad the first four bytes of this file with 0A 00 00 00 which is the number of entries...G4143
I found this at this web site- http://www.psg.com/~dlamkins/sl/chapter19.html
“the implementation is not required to directly map the specified :ELEMENT-TYPE onto the underlying file system; an implementation is permitted to alter the external format so long as data read from a binary file is the same as that written using the same :ELEMENT-TYPEâ€
Which is O.K. But why the padding of four bytes which seems to represent the number of entries? I'm just curious why this happens since it doesn't happen if the byte size is 8 or greater(at least I haven't experienced it with any other sizes)...G4143
Code: Select all
#! /usr/bin/clisp
(setq opstr (open "/home/share/test/myfile" :direction :output :element-type '(unsigned-byte 7)))
(let ((val 0))
(loop
(format t "~&~a" "enter a number, 0 to exit->")
(setq val (read))
(write-byte val opstr)
(when (= val 0) (return 0)))
)
(close opstr)
(setq opstr (open "/home/share/test/myfile" :direction :input :element-type '(unsigned-byte 7)))
(let ((val 0))
(loop
(setq val (read-byte opstr))
(format t "~&val-> ~s~%" val)
(when (= val 0) (return 0)))
)
(close opstr)