[Mono-bugs] [Bug 76218][Nor] Changed - Tokenizer/Seekable stream bugs.

bugzilla-daemon at bugzilla.ximian.com bugzilla-daemon at bugzilla.ximian.com
Tue Sep 27 12:23:54 EDT 2005

Please do not reply to this email- if you want to comment on the bug, go to the
URL shown below and enter your comments there.

Changed by rharinath at novell.com.


--- shadow/76218	2005-09-27 12:14:26.000000000 -0400
+++ shadow/76218.tmp.14964	2005-09-27 12:23:54.000000000 -0400
@@ -10,12 +10,13 @@
 Component: C#
 AssignedTo: rharinath at novell.com                            
 ReportedBy: miguel at ximian.com               
 QAContact: mono-bugs at ximian.com
 TargetMilestone: ---
+Cc: atsushi at ximian.com,martin at ximian.com
 Summary: Tokenizer/Seekable stream bugs.
 >     Please download this:
 >       http://primates.ximian.com/~miguel/tmp/fileCopier.tar.bz2
@@ -120,6 +121,19 @@
 When I saw this patch for the first time on the list, I remember
 asking  Atsushi about the performance implications of adding more
 tests to the pipeline. 
 But it turned out that his path consumed less memory and was faster
 than our extra layer (SeekableStream) which impacts every read.
+------- Additional Comments From rharinath at novell.com  2005-09-27 12:23 -------
+I have a rewrite that gives up any hope of trying to match up with the
+underlying Stream -- so no more bugs due to us guessing the number of
+bytes a given number of chars occupied originally.
+For the gain in simplicity, we lose the ability to seek arbitrarily in
+the file.  We can only seek within 1024 chars, effective limiting our
+lookahead to that.  It's much cheaper than the old code, and supports
+almost arbitrary (upto 1024 chars) seeks.  If a parser cannot decide
+in 1024 bytes, it might as well give up ;-)
+Patch attached.

More information about the mono-bugs mailing list