This is the mail archive of the
mauve-discuss@sources.redhat.com
mailing list for the Mauve project.
Re: StreamTokenizer
Yes, this was discussed, but I'm not sure the closure was posted back to the list. The bug is in the implementation of StreamTokenizer. The test case is correct as is; the patch is not correct.
On Tue, Sep 17, 2002 at 03:21:18PM -0600, Tom Tromey wrote:
> >>>>> "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
>
>
--
Daryl Lee
Marietta, GA