Re: [RFC] how to get the size of a malloc(9) block ?

Luigi Rizzo <rizzo <at> iet.unipi.it> writes:

> ... 
> > So far, the options could be as follows:
> > - realloc_flags(p, s, option)
> >   where option is one or a combination (where appropriate) of:
> >   REALLOCF_ANY                - default (move or no-move; regular
> > realloc())
> >   REALLOCF_NO_MOVE            - no-move
> >   REALLOCF_ELASTIC            - combined with REALLOCF_NO_MOVE
> >   REALLOCF_FORCE              - combined with REALLOCF_NO_MOVE
> >   REALLOCF_FALLBACK_ANY       - combined with REALLOCF_NO_MOVE or its
> >                                 derivatives like REALLOCF_ELASTIC, etc
> >
> 
> just five ? for a (quote) "clean, safe and maintainable API",
> I'd probably also add a few more, such as
> REALLOCF_ALWAYS to trigger bugs on bad assumptions in the code,
> REALLOCF_I_AM_FEELING_LUCKY for the newbies, and
> REALLOCF_REAL_PROGRAMMERS_NEVER_DO_THAT_I_WILL_PANIC
> for skilled folks.
> ...
These are more or less part of current implementation of realloc() :-)

But seriously, the new API takes advantage of current logic - the no-move
is already implemented as part of default.
It will not (and should not) interfere with current implementation-specific
details; it will just be smarter and useful thru its options by asking
specific requests, some of which could be already be partially satisified
now (think of that extra, unused allocated space, if present), thus giving
a programmer more power in one call.

Adding some if-else logic and perhaps limited code restructuring will
yield a really powerful, functional API.

Some of the hidden bugs in current realloc() & co, if any, will be
discovered during testing of new implementation (which will be more 
specific and thus less forgiving).

Think of it as being presented with a chance to become part of history,
as a co-creator of a new-and-improved memory management function,
admittedly being many OS' and libraries' Achilles' heel :-)
 
jb