MAD changes
Andrew V. Samoilov
kai at cmail.ru
Mon Nov 5 08:54:47 UTC 2001
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.
More information about the mc-devel
mailing list