From: Alan R. <ala...@gm...> - 2006-05-01 16:40:17
|
It appears that read-line sign extends character with their top bit set to 16 bit char codes. So (char-code (char (read-line (make-string-input-stream (string (code- char 170)))) 0)) correctly returns 170, but put that same character in a file foo.txt and (char-code (char (with-open-file (f "~/Desktop/foo.txt") (read-line f)) 0)) returns 65450 Is this behavior intentional? -Alan |
From: Peter G. <pe...@ar...> - 2006-05-01 23:04:14
|
On Mon, 1 May 2006 at 12:40:03 -0400, Alan Ruttenberg wrote: > It appears that read-line sign extends character with their top bit > set to 16 bit char codes. > > So > > (char-code (char (read-line (make-string-input-stream (string (code- > char 170)))) 0)) > > correctly returns 170, but put that same character in a file foo.txt and > > (char-code (char (with-open-file (f "~/Desktop/foo.txt") (read-line > f)) 0)) > > returns 65450 > > Is this behavior intentional? No. It looks like there might be a bug in line 195 of FileStream.java: char c = (char) inputBuffer[inputBufferOffset++]; Maybe that should be: char c = (char) (inputBuffer[inputBufferOffset++] & 0xff); as in line 494. Please let me know if this completely untested suggestion is helpful... -Peter |
From: Alan R. <ala...@gm...> - 2006-05-02 05:11:30
|
It is. Thanks! -Alan On May 1, 2006, at 7:04 PM, Peter Graves wrote: > It looks like there might be a bug in line 195 of FileStream.java: > > char c = (char) inputBuffer[inputBufferOffset++]; > > Maybe that should be: > > char c = (char) (inputBuffer[inputBufferOffset++] & 0xff); > > as in line 494. > > Please let me know if this completely untested suggestion is > helpful... > > -Peter |