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. _______________________________________________ Mc-devel mailing list [EMAIL PROTECTED] http://mail.gnome.org/mailman/listinfo/mc-devel
