Re: MAD changes

["Andrew V. Samoilov" <kai cmail ru>]

Pavel Roskin wrote:

> Hello, Andrew!
>
> > I suggest this patch to incorporate into cvs.  Glib support enabled
> > again now - sorry Pavel, but without it builtin editor fails on each
> > search.  I write mad_get_current_dir to use instead of g_get_current_dir.
> > Also mad_tempname now has file and line parameters.
>
> No need to say sorry.  I disabled Glib support before 4.5.55 because MAD
> didn't take care of some functions in Glib allocating memory (which was
> especially bad for gmc).  If you can reimplement them all (fortunately
> we don't care about gmc now), then it's fine to reenable Glib support.
>

Sometimes I think about something like naturalize_glib_memory_area()
for g_strdup_printf, g_get_current_dir and so on.

>
> Better yet, we could make Glib use malloc from MAD (sorry, I cannot
> check right now whether it's possible).

>
> Last time I checked, the editor was failing for a real reason - it used
> Glib malloc() to allocate the memory and standard (i.e. libc) free() or
> vice versa.  This is a real problem, and it should be fixed.  Glib is
> not guaranteed to use the same memory pool as Libc.  In fact, I remember
> seeing comments saying that it's the real issue on *BSD.
>
> Of course, having Glib support is better than not having it, so please
> go ahead with your patch, but please realize that the problem in the
> editor is real.  The ChangeLog should be changed accordingly.
>

I found some these places.  Patch will be commited soon.

>
> In order to simulate the worst case scenario, MAD should use two separate
> pools for malloc() and g_malloc().  But it can be done later.
>

Why we can't add

#define free g_free
#define strdup g_strdup
. . .

and so on in edit.h? It is easiest way.

Regards,
Andrew.