Re: new version of MAD

[Pavel Roskin <proski gnu org>]

Hi, Steef!

> > I don't understand why you removed support for glib functions, such as
> > g_free().
> That's only because I branched off mad.c about two years ago (probably
> from version 4.1.35). the g_ functions weren't even in it back then.

I see.  This means that you are not aware of the current state of memory
allocation and debugging in MC, which has changed dramatically.

> > 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.
> Look, I do not want to waste my time on playing roulette with you and
> having to estimate my "chances" on what goes into midnight commander and
> what does not. Remember the big argument about the small key_translator
> patches?

Strange, I searched both mc gnome org and mc-devel gnome org and could not
find the word "key_translator".  It must have been long ago and I probably
didn't participate.

You don't need to "play roulette".  Small, self-contained, well-documented
patches fixing real problems in the current code will be applied earlier
or later.

The real problem now is that MAD doesn't work at all because it doesn't
know about g_get_current_dir(), so MC crashes as soon as it tries to free
the result.

If nobody can use MAD with the current code there is no point in
"improving" it.

glib has its own memory debugging support.  It is done by using dmalloc.
Improving dmalloc support would be a better idea, because not only MC uses
it.

We could actually remove glib support from MAD and then gradually
eliminate all non-glib memory operations from MC.  When they are
eliminated, MAD can be removed.  In this case improving MAD doesn't seem
to be worth the trouble.

Another way would be to make MAD work with glib.  I haven't tried dmalloc
support yet, so I don't know whether MAD can add any value to it.

> That's why I like you to tell me which features you like, and which you
> do not like, so I can spare us the bandwidth on rejecting my patches
> later on.

Ok.  My advice is to get the current code.  Otherwise we are talking about
different things.

> The way MAD works is by allocating extra bytes at the start and at the
> end of a block. This means that the actual position of the data is
> shifted towards a higher region in memory. On the intel architecture,
> this is ok. On the MIPS it is not, since the processor cannot address
> certain datatypes at uneven addresses. with the current implementation
> of MAD (v. 4.5.54) 4 extra bytes are allocated as signature. This means
> that every datatype on MIPS bigger than 4 bytes will generate a
> BUS_ERROR when the data is stored/accessed in the MAD memory handle.
> This can be partly solved by using the bigger (8 byte) signatures I've
> used in mad-new.c.

Maybe this can be completely solved by using glib-based functions?

> > That's why it's better to split your patch so that its parts are readable.
> IT IS NOT A PATCH!

I meant your future patch, if you ever make one.

-- 
Regards,
Pavel Roskin