[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Nano-devel] solving a history bug in nano [patch]

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)

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.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]