Re: [PATCH] Don't truncate the history file when history size is unlimited

[Patrick Palka <patrick at parcs dot ath dot cx>]

On Tue, Jun 16, 2015 at 10:53 AM, Patrick Palka <patrick@parcs.ath.cx> wrote:
> We still do not handle "set history size unlimited" correctly.  In
> particular, after writing to the history file, we truncate the history
> even if it is unlimited.
>
> This patch makes sure that we do not call history_truncate_file() if the
> history is not stifled (i.e. if it's unlimited).  This bug causes the
> history file to be truncated to zero on exit when one has "set history
> size unlimited" in their gdbinit file.  Although this code exists in GDB
> 7.8, the bug is masked by a pre-existing bug that's been only fixed in
> GDB 7.9 (PR gdb/17820).
>
> gdb/ChangeLog:
>
>         * top.c (gdb_safe_append_history): Do not call
>         history_truncate_file if the history is not stifled.
>
> gdb/testsuite/ChangeLog:
>
>         * gdb.base/gdbinit-history.exp: Add test case to check that
>         an unlimited history file does not get truncated on exit.

I had written some extra stuff in the commit message within the patch
file  itself and then I overwritten it by running "git format-patch"
again...  This is basically what I wrote:

The reason I had so much trouble with writing the test case because I
failed to realize that there are two code paths for writing to the
history file: one for writing to a non-existing history file (i.e.
creating one) and one for appending to an existing history file.  The
bug only manifests itself when appending to the history file, not when
writing to it.  Thus the test has to stop/start GDB twice in order to
run both code paths and to trigger the bug.

By the way, what do you think about unsetting
HOME/HISTSIZE/GDBHISTFILE somewhere higher up in the testsuite
infrastructure?  It would be nice if individual tests did not have to
worry about such environment variables being leaked from userspace.