]> ncurses.scripts.mit.edu Git - ncurses.git/blobdiff - man/curs_memleaks.3x
ncurses 6.0 - patch 20170107
[ncurses.git] / man / curs_memleaks.3x
index 5ebc0d066fa51609b4a28cf6c30bf12282044487..c93dd28185bfd45d77893cab2b2f33df847aa845 100644 (file)
@@ -1,5 +1,5 @@
 .\"***************************************************************************
-.\" Copyright (c) 2008,2010 Free Software Foundation, Inc.                   *
+.\" Copyright (c) 2008-2010,2017 Free Software Foundation, Inc.              *
 .\"                                                                          *
 .\" Permission is hereby granted, free of charge, to any person obtaining a  *
 .\" copy of this software and associated documentation files (the            *
@@ -26,7 +26,7 @@
 .\" authorization.                                                           *
 .\"***************************************************************************
 .\"
-.\" $Id: curs_memleaks.3x,v 1.3 2010/12/04 18:40:45 tom Exp $
+.\" $Id: curs_memleaks.3x,v 1.4 2017/01/07 19:25:15 tom Exp $
 .TH curs_memleaks 3X ""
 .na
 .hy 0
@@ -50,7 +50,7 @@ That compiles-in code that frees memory that normally would not be freed.
 .PP
 Any implementation of curses must not free the memory associated with
 a screen, since (even after calling \fBendwin\fP), it must be available
-for use in the next call to \fBrefresh\fP.
+for use in the next call to \fBrefresh\fP(3X).
 There are also chunks of memory held for performance reasons.
 That makes it hard to analyze curses applications for memory leaks.
 To work around this, one can build a debugging version of the ncurses