Comment # 4
on bug 8859
from Alexis La Goutte
>checksum_bad and checksum_good are oddballs. I would expect them to act as a boolean for existence, but you actually have to check ip.checksum_bad==1 for example. If checksumming is enabled, then PROTO.checksum_bad==1 implies PROTO.checksum_good==1 (and vice versa). Why do we have two fields for this?
It is for colorfilter ?
>proto_item*
>proto_tree_add_checksum(proto_tree *tree, checksum_t* checksum_hfs, tvbuff_t *tvb, gint start, gint length, guint32 (64?) chsum_expected);
>with checksum_t being a structure that contains all of the necessary hfs (checksum, good, bad, expected?, ett_ for "checksum tree", etc) and expert_info. >It beats having to pass that many parameters into the function.
+1
> Having a guint32 for checksum should cover most dissectors. We may not get ALL dissectors with the new API, but I think this casts as wide a net as possible (and note many dissectors may need to add a few more hfs_ in order to use this API, but the consistency is desired)
use callback function for checksum ?
You are receiving this mail because:
- You are watching all bug changes.
