Re: new version of MAD

[Steef Boerrigter <sxmboer sci kun nl>]

Pavel,


> 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.


> Have you tried to run MC with your MAD?  I believe you would get a lot of
> warnings.
That's why I tried to be specific about the fact that the files I just
sent you AREN'T UPGRADES, but you only have to evaluate which of the
main features you like and which ones you do not like, so I can patch
those features into the current mad.c. That would mean a merger of the
two versions, so g_ and other improved features of mad.c in mc-4.5.54 DO
NOT GET LOST.

> 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?
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.

> 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.

No, that's not the issue here. The issue is alignment. Perhaps you're
not familiar with other architectures than intel and alignment problems?
Just in case let me explain briefly.
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.
Also, the memory blocks have to have a size of a multitude of those 8
bytes, otherwise a BUS_ERROR occurs on the END_SIGNATURE.

Now, that's all fine. However there is a downside: Memory errors on, for
instance, char[] variables only get detected when they cross the
alignment barrier. This is especially unwanted because of the common "of
by one" errors found in many string operations. (I specifically mention
the closing \0 after the text which crosses the allocated string length)

Preferably, we would like to know the datatype being allocated so we can
choose the correct alignment and solve this barrier issue. For malloc I
can't see how, but for calloc, the issue can be solved, because we give
it an explicit sizeof(datatype) argument.

Another way to fix the bug is to put the END_SIGNATURE in memory using a
string operation, but that becomes flaky.

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


Steef