[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
signature.asc
Description: PGP signature
- A Valgrind-observant ncurses, Steve Litt, 2024/06/20
- Re: A Valgrind-observant ncurses, Bill Gray, 2024/06/20
- Re: A Valgrind-observant ncurses, G. Branden Robinson, 2024/06/20
- Re: A Valgrind-observant ncurses, Thomas Dickey, 2024/06/20
- Re: A Valgrind-observant ncurses, Michael D. Setzer II, 2024/06/20
- Re: A Valgrind-observant ncurses,
Thomas Dickey <=
- Re: A Valgrind-observant ncurses, Steve Litt, 2024/06/23
- Re: Ctrl-L cleaning the screen, Thomas Dickey, 2024/06/23
- Re: A Valgrind-observant ncurses, G. Branden Robinson, 2024/06/20
- Re: A Valgrind-observant ncurses, Bill Gray, 2024/06/20
- Re: A Valgrind-observant ncurses, G. Branden Robinson, 2024/06/20
- Re: A Valgrind-observant ncurses, Thomas Dickey, 2024/06/21
Re: A Valgrind-observant ncurses, Thomas Dickey, 2024/06/20