> DN> I'm still not sure what you're attempting to achieve that
 > DN> realloc() does not do already.

 > Stand alone functions.

But "stand-alone functions" are most useful when they are
compiler independant. You're talking to someone who has dragged a lot of
code through a lot of compilers over the years, and and number one priority
is not only portability (which is actually the lesser concern, and I don't
hold to any "ideal" portability standard that is of little
practical use for the platforms I develop for; for example, I blatantly
assume ASCII is the default 7-bit character set, otherwise I'd waste a lot
of time fiddling about with character set and data file format issues), but
portability to different environments and compilers, even on the same
platform.

The advantage is obvious: you can pick up your code and use it elsewhere in
a different job, give it to someone else to use or maintain, put it away
for four years and dig it out later - and the code requires little or no
modification. That's called reusability. Code which is compiler (and maybe
version) dependant does not have that attribute.

Don't get me wrong - there ARE cases in which you do have to fiddle about
with #ifdef's and so forth to maintain portability. But in cases where it
can be easily avoided (as the current issue is), then it should be. IMHO.


 > If a function is meant to alter the passed variable in a way that it will
 > increase the size , it has two choices.

 > 1. Assume. (the caller properly allocated the required memory).
 > 2. Re-allocate. (the size of the variable to the required length).

Or your program can keep track of the memory itself. It only takes one or
two variables.

If you prefer an OOP style of writing C code (which I do), then doing this
is trivial, and largely invisible to the user of the code. You can optimise
your allocations to grab larger blocks of data and reallocate as it is
required. I have a dynamic array module which does that - the code is not
only reusable in different environments, but it is very portable as well -
the point is, if I want/need dynamic arrays (that is, ones that resize
themselves automagically so you don't have to really think about it), you
just #include the header, link with the library, use the interface provided
by the functions prototyped in the header, and that's that.

My experience is that the need to reallocate almost always stems from one
of two scenarios. The first is an array, as I've just mentioned. The second
is a buffer that contains text, which you are adding, removing or searching
(such as you'd find in a text editor). Or some variation or combination of
these. Since I use two front-ends for these tasks, I never even have to
*think* about reallocation, since it is embedded in the array and
textbuffer modules. These modules already keep track of the size of memory
blocks - they have to, since they need to check for overflow when something
is added.


 > It seems a waste to duplicate a table, which would normally be somewhere
 > in the environment already, even though i do realize, this would be very
 > compiler specific, to say the least.

No, no "table" - just a single variable of size sizeof(size_t)
for each block you want to manage.


 > This will come as a shock, but i'm not a professional programmer, so
 > any time i spend on (perhaps stupid) things like this is mainly for fun,
 > and in my spare time, so as long as i'm not losing money...:)

I'm not picking bones, Frank, really - I'm just trying to convince you that
a compiler/version specific solution is no solution at all in the long run.
You could switch compilers tomorrow and face the choice of either tracking
down how THAT compiler manages its heap (or, in some cases, how the
operating system does when malloc() is just a direct front-end for the OS),
or you wind up rewriting all your code. Either way, you're creating work
for yourself.

IMHO, it is better to do the thing right the first time and avoid work in
the future. I'm not particularly interested in reinventing wheels :-) - I'd
rather actually achieve something at the end of the day that works, and
works reliably.

regards,
David

--- MaltEd/2 1.0.b6