Re: Big PDUs

[John N. <jb...@ca...>]

John> Sure -- I agree with you.  It will have to be via an extra
John> parameter to each asn_realloc_rbuild_<type> function though --
John> we can't overload the packet buffer pointer semantics.

Wes> Sure you can.  If its NULL, which you should check anyway, you
Wes> shouldn't realloc.

  I don't understand.  If the packet buffer pointer is NULL, how am I going to 
do any encoding at all?  There's nowhere to write data to, and no pointer to 
call realloc() on.  But if it's not NULL, how can I tell whether or not I'm 
allowed to call realloc() on it?  This doesn't help with the situation where I 
have a buffer that I don't want realloc()ed (perhaps it's on the stack) but I 
*do* want something encoded into it (if it fits).  Also I think it's okay to 
call realloc() with a NULL pointer -- and it's quite nice too for these 
functions since it means the caller doesn't have to allocate any memory at all 
(though they do have to free() it, so that's sort of confusing).

Wes> Other question:  do we really need the function names to change?  And
Wes> if so, "realloc_" is a bit long.  But I don't care all that much.

  Mmm.  Don't really care -- this is one of the least visible APIs I would say.  More generally (to answer Dave's question) I'd prefer to stick to the current names and (in particular) avoid horribleNewCapitalisedFunctionNames, ugh!  Although there are places crying out for changed names too.  Hey that was vague. 

  Anyway, in re-doing the API with optional reallocation I appear to have broken v3 all over again... grr.

John
-- 
// Dr. John Naylon // Senior Software Engineer // Cambridge Broadband Ltd.
// The future of broadband wireless access  // www.cambridgebroadband.com