we might want to add also:
- e_packet_strdup
- e_packet_strdup_printf
- e_packet_memdup
- e_capture_strdup
- e_capture_strdup_printf
- e_capture_memdup
L
On 7/1/05, Peter Johansson <Peter.Johansson@xxxxxxxxxxxx> wrote:
> I also noticed that the draft implementation is not complete, hence my
> comment on future enhancements. I definately think your idea to unify
> dynamic memory allocation/dellocation is great, which is why I threw
> myself over the source to try to make the draft a little easier to make
> changes to that will apply for all emem_chunk_t types at once.
>
> When it comes to the api I guess they are reasonable (without having
> verified against every other usage of g_malloc).
> Perhaps the emem_packet_alloc and emem_capture_alloc functions should
> return a void* rather than a char* to be consistent with the return value
> of g_malloc?
>
> / Peter
>
> ronnie sahlberg said:
> > 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
>
--
This information is top security. When you have read it, destroy yourself.
-- Marshall McLuhan
