RE: g_malloc and malloc

As soon as I can update from SF, I'll check but when I wrote the msg, many = 2. 
:)
I always works in HEAD. Sorry I forgot to specify but it was implicit by glib 
uses.

One thing I wanted to know is why malloc is still used and not only g_malloc.

By the way, in my configuration, in debug build, g_malloc/g_free use the 
release CRT and malloc/free use the debug one. This is why I get an assert.

M-A

-----Original Message-----
From: Scott Klement [mailto:klemscot@xxxxxxxxxxxx]
Sent: 12 août, 2003 19:10
To: Linux 5250 Development Project
Subject: Re: [LINUX5250] g_malloc and malloc

> There are many inconsistencies in memory allocation usage. Memory is
> often allocated with malloc() and deallocated with g_free() or the
> inverse. Is someone currently looking at this or should I submit a patch
> (convert everything to glib), which represents many files?

I just did a quick search for everything using free() in 0.17.x (since
that branch uses glib, and there's only a handful of free() calls) and
found that EVERYTHING that calls free() is allocated with malloc().

I then checked for things that call malloc() and made sure that everything
that uses malloc() is freed with free().   I found only one place where
that happened (in telnetstr.c).

I've committed that change to CVS.

>
> In my environment, I get an assert on each misuse, which is quite
> bothering and is normal though since this is a Bad Thing.
>

Please make sure that you're not mixing files between 0.16.x branch and
0.17.x branch.  There should be no g_malloc() or g_free() on the 0.16
branch.   On the 0.17 branch, everything that's malloc() should be free()
and everything that's g_malloc() should be g_free(), at least in CVS.

> I wonder why nobody cared before?

Because g_free just calls free, behind the covers?   and g_malloc just
calls malloc() behind the covers?   So, you wouldn't even notice the
difference, unless you turned glib's memory profiling on?