Wireshark · Ethereal-dev: Re: [Ethereal-dev] Re: [Ethereal-cvs] rev 17395: /trunk/epan/: emem.c

[LEGO <luis.ontanon@xxxxxxxxx>]

Right... And there's no doubt g_error is more polite than g_assert. :-)

BTW, I think that your proposal for guard edges would be much better.
As we would abort while corrupting with a clean stack trace instead of
exiting much after the prolem was (specially with se_alloc).

On 2/24/06, Gerald Combs <gerald@xxxxxxxxxxxx> wrote:
> I certainly hope so.  Several dissectors use emem-allocated memory for
> pointers and other sensitive data.  If they get overwritten I'd like to
> inform the user, then make a hasty exit.
>
> LEGO wrote:
> > Doesn't g_error exit as well?
> >
> > On 2/24/06, gerald@xxxxxxxxxxxx <gerald@xxxxxxxxxxxx> wrote:
> >> User: gerald
> >> Date: 2006/02/23 05:12 PM
> >>
> >> Log:
> >>  Print an error when we detect memory corruption.  Fix a typo in a comment.
> >>
> >> Directory: /trunk/epan/
> >>   Changes    Path          Action
> >>   +5 -5      emem.c        Modified
> >>
> >>
> >>
> >> http://anonsvn.ethereal.com/viewcvs/viewcvs.py?rev=17395&view=rev
> >> _______________________________________________
> >> Ethereal-cvs mailing list
> >> Ethereal-cvs@xxxxxxxxxxxx
> >> http://www.ethereal.com/mailman/listinfo/ethereal-cvs
> >>
> >
> >
> > --
> > This information is top security. When you have read it, destroy yourself.
> > -- Marshall McLuhan
> > _______________________________________________
> > Ethereal-dev mailing list
> > Ethereal-dev@xxxxxxxxxxxx
> > http://www.ethereal.com/mailman/listinfo/ethereal-dev
>
> _______________________________________________
> 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