persistent history file truncation can corrupt it

[Thorsten Glaser]

The comment in histrap.c:hist_skip_back() is accurate: the code cannot work.

15:15⎜«ft:#grml» mira|AO: I've got an mksh, which uses 166750xxxx (I don't rememer where it started
     ⎜ exactly) as the history event number. What's not with that?

15:30⎜«ft:#grml» mira|AO: Yes, I'm setting HISTFILE.
15:31⎜«ft:#grml» it's ~/.mksh_history for me, even.

15:31⎜<mira|AO:#grml> ft: what size was the history file by then?
15:32⎜«ft:#grml» mira|AO: I can't say. 1.5-2000 maybe.
15:32⎜«ft:#grml» mira|AO: lines

15:37⎜<mira|AO:#grml> what's your $HISTSIZE ?
15:37⎜«ft:#grml» mira|AO: 500 (so, I guess the file was even shorter. ;-))

No idea on the huge source->line, but the corruption may very well have been from truncation.
166750xxxx can be 636407E0 to 63642EEF

63642E = "cd." in ASCII
636420 = "cd " would also have been possible.

This can have happened if the line number of the first entry after truncation, modulo 256, was 255.

Since persistent history is disabled by default, this has low impact but should nevertheless be fixed.

[Thorsten Glaser (mirabilos)]

I’ve done what I can to this code without rewriting it. Needs to be tested now. ft says it works for him.

[Thorsten Glaser (mirabilos)]

fixed in R40e and HEAD, but the entire code really needs work… the truncation code cannot possibly work, but how to do it otherwise…