On Jul 17, 2017, at 12:53 PM, Sultan, Hassan via Wireshark-dev <wireshark-dev@wireshark.org> wrote:
> One thing we could do rather than create more fields is to keep the fields > as-is, but find a way to store in the header_field_info structure attached to > the field the original type & encoding (meaning : what the field actually is > on the wire). A header_field_info structure describes a "named field", rather than an instance of that field in a packet. Not all instances of a field have the same encoding, if by "encoding" you mean the ENC_ values that describe the rules for encoding values as bits. > The current field_info seems to properly represent length & offset (at least > for the cases in http), so really the important stuff missing is data type & > encoding. A field_info structure represents an *instance* of the field; *that* would be the place to store the encoding. > Storing that in the header_field_info would limit the memory consumption > increase as well since it wouldn't grow with the # of frames parsed. If the values in the field_info structure are sufficient to find all the bits that generated the value, and where the field's value is extracted in that fashion rather than being computed from the raw value or from other values, perhaps we could defer extracting the value until it's needed, not store it in the structure, and have a union containing the actual value (or a pointer to it, for non-"small" values) for fields with computed values and encoding etc. information for fields with extracted values. ___________________________________________________________________________ Sent via: Wireshark-dev mailing list <wireshark-dev@wireshark.org> Archives: https://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
