[ronnie sahlberg <ronniesahlberg@xxxxxxxxx>]

1 and 2 are good points.

the current implementation will not work anyway since it never reuses
more than the very first memchunk alloced after they have been
released anyway.
it needs a free/used list of such emem chunks from a top node.


but the purpose was not a functioning code, but opinions about the api
and the semantics:
1, multiple allocations
2, release everything allocated in 1 in one quick function.

i.e. one can alloc as much as one wants  but free() frees everything at once.



On 7/1/05, Peter Johansson <Peter.Johansson@xxxxxxxxxxxx> wrote:
> ronnie sahlberg said:
> > List
> >
> > Attached are two new files with a new FAST api to provide memory
> > allocation and automatic garbage collection with an allocation
> > lifetime of
> > either    until-next-packet
> > or until-next-capture-file
> 
> I had a quick look at the source and have comments on the function
> emem_capture_alloc:
> 1) Why is the size parameter to emem_capture_alloc signed? Why is it
> *only* 32-bit? Should perhaps size_t be used instead?
> 2) Why is the size rounded to the nearest higher 4-byte boundary. This
> assumes a 32-bit platform, right? Why not round to an 8 byte boundary
> instead to make this work on 64-bit platforms too!?
> 
> I took the liberty of changing the implementation a bit as can be seen in
> the attached modified_emem.c file. There I have made changes for my
> questions in 1) and 2) above as well as rewriting it a bit to be a bit (in
> my personal oppinion) more generic for future enhancements.
> 
> Regards, Peter
> 
> _______________________________________________
> Ethereal-dev mailing list
> Ethereal-dev@xxxxxxxxxxxx
> http://www.ethereal.com/mailman/listinfo/ethereal-dev
> 
> 
> 
>