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.
