At this point I have few questions:
- How do I malloc something so that it can be freed after an exception?
- How do I free what's being malloced that way?
- Since some of the proto.c functions that THROW are used during setup
by some dissectors (I know MATE does for sure I think others do as
well); I wonder on what would happen if an exception is thrown. Are
we already in a TRY frame during protocol registration/handoff and
preferences setup or should that be created in case something is
thrown during that phase?
- I have another more general question related to the TRY-CATCH
mechanism that ethereal uses. can TRY "blocks" nest? (is there a stack
for long jumps?)
Thanks
On Tue, 22 Mar 2005 23:15:45 +0100, Ulf Lamping <ulf.lamping@xxxxxx> wrote:
> Hi List!
>
> Of course, dissectors should be bug free (so no assert's necessary :-),
> but as we all know they certainly often aren't.
>
> As assert's being the main causes for several recent crashes in Ethereal
> (ask the buildbot and others), there are a lot of (362 to be precise)
> g_assert calls (and alike ones) in both the dissectors and dissector
> support code (e.g. epan/ftype).
>
> With the current g_assert behaviour, typical user's will simply get
> annoyed by a message that an assert has occurred (and won't have the
> knowledge to do anything against it). They usually blame it on the
> developers (well, which is correct BTW) and click away that message and
> will be annoyed that their data has just gone, which is the worst
> behaviour we could provide at all IMHO :-(
>
> Should we banish these g_assert calls from epan completely to provide
> much better program stability?
>
> I personally like assert's, but as we have the DISSECTOR_ASSERT call,
> which throws a DissectorError exception, is a much better choice in that
> code part in my opinion.
>
> It's not that I don't want to fix bugs (I'm doing that continuously for
> the time being), but IMHO it's more important to have a non crashing
> Ethereal than to fix the bugs.
>
> Single packets marked as [Dissector Bug] will be much more user friendly
> than a crash because of a g_assert().
>
> Any objections against this?
>
> Regards, ULFL
>
> _______________________________________________
> 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
