|
From: | Tito |
Subject: | Re: [Nano-devel] solving a history bug in nano [patch] |
Date: | Mon, 30 May 2016 21:20:04 +0200 |
User-agent: | Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Icedove/38.8.0 |
On 05/30/2016 05:51 PM, address@hidden wrote:
On Mon, 30 May 2016 09:20:24 +0200 Benno Schulenberg <address@hidden> wrote:try instead of (size_t)-1 the values 100, 255, 32000, 65535. If none of those segfault, then at least we have a workaround: nobody is going to type sixty-five thousand characters to search for.No one will ever need more than 640k of memory! The value might be converted to a signed int somewhere inside find_history. Perhaps use the largest value possible that can never be negative? #define SIZE_T_HALF_MAX ((~(size_t)0)>>1)
Hi, what I would do is (based on a very superficial look at the code): 1) when reading in search history from a history file set it to the length of the longest string and not more than SIZE_T_HALF_MAX 2) when search strings are typed in by the user increase the size accordingly if the string is longer than the longest string stored up to SIZE_T_HALF_MAX this would avoid in most use cases to waste memory as search strings in my experience are rather short. Ciao, Tito
[Prev in Thread] | Current Thread | [Next in Thread] |