talloc()

[Elrond]

Nice to see you back. :)

On Thu, Aug 10, 2000 at 10:50:19AM +0200, Sander Striker wrote:
> >Here's a little be on interesting information...
> >
> >two consecutive calls to talloc() of 0 size will return 
> >pointers to the same memory location.  This has come up in 
> >prs_unistr().  If the amout of allocated space needed is 0,
> >the the str->buffer will still get assigned a memory address
> >by prs_alloc_mem().
> >
> >**and the next prs_unistr will get the same memory!
> 
> Argh...
> 
> Hmmm, does it happen often that pieces of 0 memory are first
> reserved and later realloc()'ed to something bigger?
> If this is the case and it happens a lot in marshalling I
> should maybe do a little optimization on the sma code in TNG;
> return NULL when 0 bytes are requested instead of returning
> a block off the minimal size returned by sma. Would this be
> preferred behaviour?

First and important:

One should _NEVER_ realloc memory from talloc(), that
memory is (like sma) not realy under normal
malloc/free-control.


And on the other side:

This sort of stuff is only used in the memory, that is
allocated in the process of unmarshalling to hold the
parameters, that were read from the wire. In TNG we
currently use normal g_new for this stuff. HEAD uses a
talloc to be able to free the stuff in one call outside.

For TNG I want to use (internaly) complex rpc memory
management. Some weeks ago I had the idea for it... then I
forgot it and two days ago I got a new idea, I like a lot
more. I guess, I'll write a spec to sidlc at samba.org, so
people can tell me, wether the stuff sounds useful or not.


    Elrond