[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-devel
Subject:    Re: Query on kdelibs/kdecore/io/kgrantpty.c
From:       "Boyd Stephen Smith Jr." <bss03 () volumehost ! net>
Date:       2007-07-29 14:53:30
Message-ID: 200707290953.35407.bss03 () volumehost ! net
[Download RAW message or body]

[Attachment #2 (multipart/signed)]


On Sunday 29 July 2007, Oswald Buddenhagen <ossi@kde.org> wrote about 'Re: 
Query on kdelibs/kdecore/io/kgrantpty.c':
> On Sun, Jul 29, 2007 at 02:38:26AM -0500, Boyd Stephen Smith Jr. wrote:
> > On Sunday 29 July 2007 02:15:54 am Brad Hards wrote:
> > > One that does look like an error is in kgrantpty.c
> > > Around line 149 is this line:
> > >     tty = malloc(strlen(pty) + 1);
> > >
> > > That never gets free()'d that I can see.
> > >
> > > Does that count as a bug, or is it OK because this is a standalone
> > > application and it gets cleaned up on exit?
> >
> > It's a bug, in that application.  A non-buggy OS will clean up where
> > the application doesn't though, so if the application isn't meant to
> > be long-running it shouldn't cause many problems.  (It's still a bug
> > though.)
>
> nonsense. relying on the os doing cleanup is *perfectly* ok.

I respectfully disagree, it's sloppy programming if nothing else.

> small 
> chunks aren't returned to the os anyway until the program terminates.

Any heap page can be returned to the OS, but many are actually held on to 
throughout the lifetime of the program, so small chunks are more likely to 
get "stuck" in RAM after a free().  In any case, if you don't free() the 
memory later small malloc()s can reuse it and your memory usage will 
slowly balloon.

> so as long as no allocations are done after unallocations could have
> been done and thus the peak memory usage does not increase, one can
> completely forget about freeing.

Agreed, you can "completely" forget about free()ing until your program 
decides there is at least one thing that needs to be free()d -- like maybe 
the first time you write a loop w/o fixed overhead.

> > I'd imagine that code could be fairly easily replaced with some
> > QString or QByteArray code.
>
> right. i'll instantly turn it into a .cpp file, link to QtCore and its
> ~10 dependencies, at least tripling the startup time and increasing the
> build time tenfold.
> oh, right, kgrantpty was just an example ...

Sure, fine, don't use C++ or Qt if you think their "overhead" (read: useful 
features) isn't worth it.  You should still free() your malloc()s and 
delete([])? your new\1s.  (In all but the most trivial applications that 
will never grow.)  (That means always, since all programs expand to the 
point where they can (a) send email and (b) contain a partial, buggy 
implementation of common LisP.)

-- 
Boyd Stephen Smith Jr.                     ,= ,-_-. =. 
bss03@volumehost.net                      ((_/)o o(\_))
ICQ: 514984 YM/AIM: DaTwinkDaddy           `-'(. .)`-' 
http://iguanasuicide.org/                      \_/     

["signature.asc" (application/pgp-signature)]

>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<


[prev in list] [next in list] [prev in thread] [next in thread]