[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/