Re: glib memory handling

Hi, Steef!

> Normally I would recommend fortify, but it is not completely free
> software, as one is free to use it, but not to distribute modified
> versions.
> So this convinced me that it would be usefull to improve mad.

May I suggest that you try your improved mad with something other than mc?
I think this could be a separate package.  I don't see much interest in
the MC lists about the issue.

In the meantime I'm disabling glib support in MAD - it's defunct.  Many
glib functions are not taken into account (perhaps some tricks are needed
to avoid reimplemented them all) and g_free(NULL) is considered a problem
while it is not.  Such code should not be enabled for anybody except
developers trying to fix it.

MAD without glib support has immediately detected a serious problem in
vfs/sfs.c.  MC runs after fixing it, but it's still quite unstable.

I'll not delay 4.5.55 to fix it - it may take a lot of time and it affects
very few platforms - those that use different storage for g_malloc and

Pavel Roskin

--- mad.h
+++ mad.h
@@ -46,6 +46,13 @@
 #define strndup(x, n)	mad_strndup (x, n, __FILE__, __LINE__)
 #define free(x)		mad_free (x, __FILE__, __LINE__)

+ * Define MAD_GLIB to debug allocations in glib as well.
+ * This code is not functional yet.
+ */
+#undef MAD_GLIB
+#ifdef MAD_GLIB
 /* These definitions are grabbed from GLib.h */
 #define g_new(type, count)	  \
       ((type *) g_malloc ((unsigned) sizeof (type) * (count)))
@@ -63,6 +70,7 @@
 #define g_strconcat		mad_strconcat
 #define g_strdup_printf		mad_strdup_printf
 #define g_strdup_vprintf	mad_strdup_vprintf
+#endif /* MAD_GLIB */

 void mad_init (void);
 void mad_set_debug (const char *file);

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]