The check was only done when not memory mapped, so there was a potential
out of bounds read. In addition the check only printed an error, and
didn't return and went ahead with the erronous read.
The 'loc' variable is indirectly read from the file, so in case the
history file is corrupted this could potentially lead to a crash.
Found by Coverity.
REVIEW: 128153
Currently, when unlimited scrollback is used, the files are stored in
/tmp. As noted in the bug report, this can cause issues on some
distros. The default is still /tmp but the user can selected to use
a location in their $HOME folder (QStandardPaths::CacheLocation).
This is somewhat a WIP. Allowing for the changes to take effect
immediately appears to be a gigantic mess to get to work.
CCBUG: 173283
Some distros have small /tmp and/or use tmpfs, and large history
(esp unlimited scrollback) can potentially fill disk or VM.
BUG: 173283
REVIEW: 123804
Apparently I didn't take a close look at the implementation detail of
memory-based history when I added the 'isRealCharacter' flag. That
missing information causes some wrong behaviors randomly when using
memory-based history.
This is a follow up of commit dc2b64d33(for BUG 188528)
BUG: 294330
BUG: 299252
FIXED-IN: 4.8.4
The old way has one problem: HistoryFileNone::isUnlimited() returned
true because HistoryFileNone::maximumLineCount() returned 0. Although
that did not cause problem for practical usage, it was still quite odd.
The code of class HistoryScrollBuffer and HistoryScrollBlockArray are
quite old and not in use for quite some time. The current implementation
for history of fixed size is class CompactHistoryType.
Maybe those deprecated classes should be totally removed , but at the
moment just leave theme there as reference.
Initialize the _readwritebalance member to 0.
If this is not initialized, at random konsole runs, the history could
not be mmaped even if lseek is slower.
Also, remove a valgrind warning about jump using unitialized value.