This is the mail archive of the
mauve-discuss@sources.redhat.com
mailing list for the Mauve project.
Re: StreamTokenizer
- From: Tom Tromey <tromey at redhat dot com>
- To: Daryl Lee <dlee at altaregos dot com>
- Cc: Mauve Discuss <mauve-discuss at sources dot redhat dot com>
- Date: 17 Sep 2002 15:21:18 -0600
- Subject: Re: StreamTokenizer
- References: <20020914182618.A7147@tigger>
- Reply-to: tromey at redhat dot com
>>>>> "Daryl" == Daryl Lee <dlee@altaregos.com> writes:
Daryl> I believe the following patch might be useful in
Daryl> gnu/testlet/java/io/StreamTokenizer/Test.java.
Daryl> < tokenize (harness, "(a).(b)", x1);
Daryl> ---
Daryl> > tokenize (harness, "(a)5(b)", x1);
Daryl> (This is a straight diff, not a CVS diff; I've never submitted
Daryl> a patch, so someone tell me if this is the wrong protocol.)
Ordinarily unidiffs are preferred; use `diff -u'.
Plain diffs are typically considered difficult to read, though
obviously in this specific instance that isn't the case.
Daryl> The original string causes classpath's number parser to fail,
Daryl> trying to parse a bare '.'. (See §3.10.2 of the Java Language
Daryl> Specification.) I believe a better solution is to make
Daryl> StreamTokenizer handle the NumberFormatException thrown by
Daryl> Double, but that is an argument for others to conduct.
ISTR this test being discussed before. As I remember it, we decided
that the test case is in fact correct. If true, that would mean that
the bug is in the Classpath StreamTokenizer, and the above patch
shouldn't be applied.
Could you try this case with the JDK and see what it does?
Tom