Re: new version of MAD

[Pavel Roskin <proski gnu org>]

Hi, Steef!

> > http://www.red-bean.com/~proski/mc/ (we probably need a better place for
> > them in the long run).
> Why don't we put the code on the GNU savannah site?
> (http://savannah.gnu.org)
> It's especially designed for projects like these, and after all, mc is
> already a GNU package.

I agree.  I just want to concentrate on the code for the next few weeks.

> Anyway, this mail was really intended to bring up the improved version
> of mad.c. As I promised you earlier this month, I have made a new mad.c
> which fixes a few problems I encountered using it for different programs
> and platforms.

I don't understand why you removed support for glib functions, such as
g_free().

The problem with g_free() in MAD is that it warns about NULL pointers,
just like free().  This is wrong - g_free() has been designed to accept
NULL pointers on all platforms.

But removing g_free() looks like ignoring the problem, not fixing it.

Have you tried to run MC with your MAD?  I believe you would get a lot of
warnings.

> I started merging the differences, but find it difficult and time
> consuming as I worked on a mad.c which branched off of mc over two years
> ago. Moreover, you may not like the chances, which would render my work
> useless altogether.

I would rather accept small changes to the current code than big changes
based on a two-years old code.

> The main features/differences are:
> - dynamic memory area handles (instead of static # 20000)
> - separate END/START signatures
> - MAD_QUICK option
> - Support for SGI Indy (and probably more RISC and or MIPS platforms)

Can you make small patches against the current code for eech of those
changes?  It would greatly increase chances that some of them will be
accepted.

> There's one more bug which I need to fix: calloc is now defined as
> mad_alloc which simply does malloc. This is not correct, since calloc
> resets (initializes to zeros) all the allocated bytes. Programs that
> rely on that feature usually crash, obviously. One cannot trivially
> replace the malloc with the calloc commands, however, since the
> alignment and start/end-sigs have to be considered for proper operation.

I don't understand the last point.  mad.h provides mad_alloc0() but it is
not used for calloc.  Do you mean that mad_alloc0 doesn't work on some
architectures?  Then fix mad_alloc0() for your architecture, and I'll fix
MAD to use mad_alloc0() for calloc() right now.

> By the way, I'm sending you the full files as the 'diff -u' files are
> bigger than the original files and I don't want you to confuse these
> files with actual patches.

That's why it's better to split your patch so that its parts are readable.

-- 
Regards,
Pavel Roskin