Re: [PATCH] Fix PR gdb/16999

[Pedro Alves <palves@redhat.com>]

On 05/14/2015 01:05 PM, Patrick Palka wrote:

>>  #1 - if HISTSIZE is non-numeric nothing happens.  I think that means
>>       bash ends up with the default history size.
>>
>>  #2 - if HISTSIZE is set to the empty string, bash ends up
>>       with unlimited history size.
>>
>> It seems to me that your patch handles both of these differently.
>>
>> #2 appears consistent with what is suggested here:
>>
>>   http://stackoverflow.com/questions/9457233/unlimited-bash-history
>>
>> "Set HISTSIZE and HISTFILESIZE to an empty string:
>>
>>  HISTSIZE= HISTFILESIZE=
>>
>>  In bash 4.3 and later you can also use HISTSIZE=-1 HISTFILESIZE=-1:
>> "
> 
> When HISTSIZE is the empty string, I think we invoke UB.  I'm not sure atoi()

I'd be very surprised if any implementation returned anything other
than zero.

> 
> I was basing this patch off of the behavior of HISTFILESIZE, not
> HISTSIZE.  This is because the behavior of HISTFILESIZE is more
> specified than that of HISTSIZE.  According to the documentation for
> HISTFILESIZE:
> 
>     Non-numeric values and numeric values less than zero inhibit
> truncation.  The shell sets the default value to the value of HISTSIZE
> after reading any startup files. ... If HISTFILESIZE is unset, or set
> to null, a non-numeric value, or a numeric value less than zero, the
> history file is not truncated.

But this says that if set to null the history file is not truncated.
AFAICS, your patch treats HISTSIZE= as leaving the size to the
default, which truncates.  Seems to me that the way to implement
"not truncate" would be to set the history size to unlimited, like
bash does (even if undocumented).

The non-numeric handling of HISTSIZE and HISTFILESIZE seems to be
different indeed.  I think that's less of an issue than
"HISTSIZE=", as people shouldn't be using non-numeric values
on purpose, though I'm fine with not truncating (thus, unlimited)
to avoid data loss on mistakes/typos.

> But unless GDB responds to both HISTSIZE and HISTFILESIZE I suppose we
> will never be truly consistent with bash since apparently both of
> these variables have different behaviors under edge cases.
> 
> So should we anyway match the behavior of bash's HISTSIZE?

Yes, I think so, at least for the "HISTSIZE=" parts, given that lots
of people will be following the stack-exchange advice of doing that
to get unlimited history in all versions of bash.

Thanks,
Pedro Alves