[Mono-bugs] [Bug 675384] XmlTextReader.ReadChars fails with nested tags.

[bugzilla_noreply at novell.com]

https://bugzilla.novell.com/show_bug.cgi?id=675384

https://bugzilla.novell.com/show_bug.cgi?id=675384#c3


--- Comment #3 from Adrian Gallero <agallero at netscape.net> 2011-02-26 17:00:36 UTC ---
Thanks for looking into the issue.

With "no reproduce" do you mean that you get "<child>a</child>" as output, or
that your expected result is empty?

I have looked at the code, and in XmlReader.cs, method ReadCharsInternal:


        // Returns -1 if it should throw an error.
        private int ReadCharsInternal (char [] buffer, int offset, int length)
        {
            int bufIndex = offset;
            for (int i = 0; i < length; i++) {
                int c = PeekChar ();
                switch (c) {
                case -1:
                    throw NotWFError ("Unexpected end of xml.");
                case '<':
                    if (i + 1 == length)    
                        // if it does not end here,
                        // it cannot store another
                        // character, so stop here.
                        return i;
                    }


When length = 1 (as in my example) and i = 0 and the character is a start of a
nested tad ("<")
it will return 0 characters read, and not advance the position.

It is impossible to advance from here, since all new calls to ReadCharsInternal
will return 0 and not move.

It actually should return 1 character read (the "<") and advance the position
by one. But I am not sure on how it could be implemented as the simplest
solution, which would fix this test case:
                case '<':
                    if (i + 1 == length)
                    {    
                        // if it does not end here,
                        // it cannot store another
                        // character, so stop here.
                        Advance(c);
                        return i + 1;
                    }

would break detection of </end> tags. So to fix this it would probably be
necessary to keep an internal buffer with more than 2 characters, and not use
the user-supplied buffer for the "</" detection.

I am really interested in knowing if you have the same code as me (I got the
latest from git, and made a git diff right now to be sure it doesn't change). I
can't see how this code could work with a 1-char buffer if it is the code I
have.

Again. thanks a lot for your time.

Regards,
   Adrian.

As it is now, the workaround seems to be to use a buffer of at least 2
characters. I think I could use that, but it would be good if it worked the
same as .NET. Again, if there is something I got wrong, please let me know.

-- 
Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.