From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 114325 invoked by alias); 15 May 2015 10:42:34 -0000 Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org Received: (qmail 114314 invoked by uid 89); 15 May 2015 10:42:34 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.4 required=5.0 tests=AWL,BAYES_00,KAM_LAZY_DOMAIN_SECURITY,SPF_HELO_PASS,T_RP_MATCHES_RCVD autolearn=no version=3.3.2 X-HELO: mx1.redhat.com Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-GCM-SHA384 encrypted) ESMTPS; Fri, 15 May 2015 10:42:32 +0000 Received: from int-mx09.intmail.prod.int.phx2.redhat.com (int-mx09.intmail.prod.int.phx2.redhat.com [10.5.11.22]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id t4FAgU1Q009629 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Fri, 15 May 2015 06:42:30 -0400 Received: from [127.0.0.1] (ovpn01.gateway.prod.ext.ams2.redhat.com [10.39.146.11]) by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t4FAgT56019113; Fri, 15 May 2015 06:42:29 -0400 Message-ID: <5555CD94.1060900@redhat.com> Date: Fri, 15 May 2015 10:42:00 -0000 From: Pedro Alves User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: Patrick Palka CC: "gdb-patches@sourceware.org" Subject: Re: [PATCH] Fix PR gdb/16999 References: <1431555450-15493-1-git-send-email-patrick@parcs.ath.cx> <555475F1.2030504@redhat.com> In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-SW-Source: 2015-05/txt/msg00378.txt.bz2 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