bug-ncurses
[Top][All Lists]
Advanced

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

Re: A Valgrind-observant ncurses


From: Thomas Dickey
Subject: Re: A Valgrind-observant ncurses
Date: Sat, 22 Jun 2024 17:19:54 -0400

On Fri, Jun 21, 2024 at 07:01:44AM +1000, Michael D. Setzer II wrote:
> On 20 Jun 2024 at 15:47, Thomas Dickey wrote:
> 
> Date sent:    Thu, 20 Jun 2024 15:47:38 -0400
> From: Thomas Dickey <dickey@his.com>
> To:   Bill Gray <pluto@projectpluto.com>
> Copies to:    bug-ncurses@gnu.org
> Subject:      Re: A Valgrind-observant ncurses
> Send reply to:        dickey@his.com
> 
> > On Thu, Jun 20, 2024 at 01:06:54PM -0400, Bill Gray wrote:
> > > Hi Branden,  all,
> > > 
> > > On 6/20/24 11:12, G. Branden Robinson wrote:
> > > > Hi Bill,
> > > > >     ...It's five blocks unless printw() is called;  apparently,
> > > > >     that function maintains a static buffer that isn't freed.
> > > > 
> > > > What do you mean by "static" here?
> > > 
> > >    Sorry,  I was sloppy in my language there.  You're right;  a 'static
> > > buffer' should be assumed to be one declared as,  say,
> > > 
> > > static char buffer[80];
> > > 
> > >    What I meant was that you have a buffer that is allocated when printw()
> > > is first called,  and possibly resized if it needs to be made larger.  On
> > > the first call to printw(),  it might allocate an 80 byte buffer,  
> > > figuring
> > > that'll be big enough 99% of the time.   Then,  when it encounters a
> > > printw() that requires 200 bytes,  the buffer is re-allocated to be (say)
> > > 300 bytes.  Subsequent calls may exceed even that limit,  and cause the
> > > buffer to be re-re-allocated to be still larger.
> > > 
> > >    Ideally,  the buffer is then freed when endwin() or delscreen() is
> > > called.  Except that doesn't happen here.
> > 
> > It shouldn't, because curses guarantees that you can do a refresh after
> > endwin and get the screen contents as they were.
> > 
> 
> Just wondering if the Ctrl-L would clean screen?

A few terminals (mostly emulators actually) will clear the screen on ^L.
DEC's hardware terminals were not among those; xterm likewise.

https://invisible-island.net/xterm/xterm.faq.html#xterm_form_feed

(the terminals that do this don't document this stuff, anyway)

> Don't know it is related in any way?
> Use dialog with my G4L project and sometimes kernel message 
> will show on screen, and using te Ctrl-L will redraw screen.
> Latest kernels have a option that by default has a value of 120.
> Changing it to 0 disabled it, but while it was at default would see 
> messages a lot.
> CONFIG_DEFAULT_HUNG_TASK_TIMEOUT=0
> 
> The Ctrl-L has aways been nice to clean up the screen.
> Know sometimes this option is overlooked.
> 
> 
> > ncurses used to use setbuf, which entails its own limitations
> > (you can NOT free its buffer), but that got in the way of handling signals.
> > 
> > ncurses could free its own I/O buffer, but since it needs other memory
> > to persist, that would be kind of pointless.
> >  
> > -- 
> > Thomas E. Dickey <dickey@invisible-island.net>
> > https://invisible-island.net
> > 
> 
> 
> +------------------------------------------------------------+
>  Michael D. Setzer II - Computer Science Instructor (Retired)     
>  mailto:mikes@guam.net                            
>  mailto:msetzerii@gmail.com
>  mailto:msetzerii@gmx.com
>  Guam - Where America's Day Begins                        
>  G4L Disk Imaging Project maintainer 
>  http://sourceforge.net/projects/g4l/
> +------------------------------------------------------------+
> 
> 
> 
> 

-- 
Thomas E. Dickey <dickey@invisible-island.net>
https://invisible-island.net

Attachment: signature.asc
Description: PGP signature


reply via email to

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