octave-bug-tracker
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Octave-bug-tracker] [bug #62152] Textscan fails in rare occurences


From: Markus Mützel
Subject: [Octave-bug-tracker] [bug #62152] Textscan fails in rare occurences
Date: Sun, 13 Mar 2022 08:36:49 -0400 (EDT)

Update of bug #62152 (project octave):

                  Status:               Confirmed => Ready For Test         
                 Release:                   6.4.0 => dev                    

    _______________________________________________________

Follow-up Comment #3:

I pushed a change to the default branch that changes to `peek_undelim` or
`get_undelim` where I think the end of the buffer can be reached. In many
places, that character might be put back to the stream if it doesn't meet some
conditions. This is realized by decrementing the pointer to the current
position in the buffer. That wouldn't work with the current design of the
buffer after a refresh.
To prevent that issue from causing trouble, I changed the buffer refresh to
retain an overlap with the previous buffer content. I chose a rather large
number of overlapping characters (25). Most probably an overlap of 3 or 4
would already be fine. But I'm not sure about that.
See here:
https://hg.savannah.gnu.org/hgweb/octave/rev/cfb708de1fc9

IIUC, there are still a few places where `tellg` and `seekg` are used when the
buffer might have been refreshed in the meantime. Afaict, that will most
likely cause that parts of the (buffered) stream are skipped.
That's not a regression from this change but was already an issue before. I'm
not sure how that can be resolved with the current design.
I'm wondering if there aren't some standard functions we could use instead of
this manual buffering...

This bug still exists on the stable branch. But all of this buffering seems to
be quite delicate, and I'd prefer to not make any intrusive changes in that
area just before a planned release.
Maybe, we could consider cherry-picking this for a dot release when we are
more certain this is fine.

Anyway, marking as ready for test for the issue reported here.


    _______________________________________________________

Reply to this item at:

  <https://savannah.gnu.org/bugs/?62152>

_______________________________________________
  Message sent via Savannah
  https://savannah.gnu.org/




reply via email to

[Prev in Thread] Current Thread [Next in Thread]