From: Godmar Back (gback@cs.utah.edu)
Date: Sat Dec 12 1998 - 22:12:22 EST
Since we have the deprecated "getInCheck()" method in SecurityManager,
I also added the deprecated "inCheck" field for an application that
needed it.
Second, I discovered and fixed two bugs in StreamTokenizer.
The first bug showed up when EOL was significant, but you had lines
with trailing spaces. In this case, the tokenizer would simply skip
over all whitespace, including the \n, until the next non whitespace.
I added a check for \n in the loop where whitespace were skipped.
The second bug was that the tokenizer would push back EOF in certain
cases. Then, it would read it again from the PushbackReader as 65535.
I wrote a test to check whether that's the correct behavior for a
PushbackReader, and although the JDK doc does not say anything about
that case, tests with Sun's JDK show that it is. It's what Kaffe does,
too.
Reading EOF as 65535 would mean that ttype was not set to EOF, which
would cause an error in my application.
A short fix would have been to simply map 65535 to EOF. However,
such a solution would not have been able to deal with the actual
character \uffff --- should there be such a character.
Therefore, I restructured the tokenizer to never push back EOF
onto the pushback reader. Instead, once an EOF is detected, it
will always return EOF when reading the next character. To achieve
this, I wrapped the call to pushIn.unread() in a function unRead() that
would check whether EOF was about to be pushed back.
I replaced all calls to pushIn.unread with calls to unRead().
Any comments?
- Godmar
This archive was generated by hypermail 2b29 : Sat Sep 23 2000 - 19:57:13 EDT