On Jul 17, 2008, at 9:36 AM, Bill Meier wrote: > The following 4 wiretap files appear to use g_error & etc in > relation to > checking for programming errors. > Q: Is the use of g_error & etc not OK in these cases ? > > buffer.c: exit,g_error > etherpeek.c: g_assert > file_access.c: g_error > k12.c: g_assert > > > ---------- > > A quick look suggests that the following 3 files are using g_assert > when > checking for file format errors. I would guess that this code should > be > changed ....
A true file format error should never result in an assertion failure or other exit. However: > ngsniffer.c: g_assert Those are actually programming errors (including the record type check - the seek-and-read routine should never be handed an offset that wasn't returned as a record offset by the read routine, and that should only happen for the record types listed). > pppdump.c: g_assert Those are, I think, also programming errors. > wtap.c: g_assert As is that (it means some read routine is saying that a *packet's* encapsulation is per-packet). We could, conceivably, have a WTAP_ERROR_INTERNAL error code, and have it return an error string describing the failing assertion or other problem; if the application gets that, it should report it as a "internal error; please report this to the developer of the application" error, showing the error string. _______________________________________________ Wireshark-dev mailing list [email protected] https://wireshark.org/mailman/listinfo/wireshark-dev
