On Jul 17, 2008, at 3:00 PM, Bill Meier wrote: > My understanding of the replies is that the current usage of g_error & > g_assert in wiretap files is OK.
Well, maybe. The problem is that we don't want to have any wiretap code to abort or exit if it finds something in the capture file that it doesn't like; however, it's not necessarily a problem if it aborts if it detects an internal inconsistency. Unfortunately, checkAPIs can't tell the difference between those two cases. Perhaps, as per my mail, we need to have an "internal error" return, so that wiretap doesn't abort for internal inconsistencies (programming errors), but the application can tell the user that an internal error happened and they should report it to the application developer (which would be the Wireshark developers for Wireshark/ TShark/capinfos/editcap/etc.). That's how we handle it for dissectors - there are macros for reporting dissector bugs, which don't cause Wireshark/TShark to exit, but they do cause an error to be reported in the protocol tree, so the user will see a "dissector bug" indication in the packet details. _______________________________________________ Wireshark-dev mailing list [email protected] https://wireshark.org/mailman/listinfo/wireshark-dev
