Re: BASE_CUSTOM and 64-bit values

[Evan Huus <eapache () gmail com>]

On Tue, Mar 26, 2013 at 2:30 PM, Guy Harris <guy () alum mit edu> wrote:
> On Mar 26, 2013, at 10:31 AM, Evan Huus <eapache () gmail com> wrote:
>
> > I'm not 100% convinced we should though - it would be more flexible,
> > but we'd be exposing some of the guts of the dissection backend into
> > 'userspace' as it were. Not a particular strong objection, but
> > something to keep in mind.
>
> I'm not sure that field values should be thought of as an internal detail; I could see some language bindings, for 
> example, wanting to translate field values into values in the language, and I could see taps wanting to request the 
> values of specific named fields and getting them as fvalue_t's.

I'm not sure language bindings really count, since they'll potentially
need access to internal details for other reasons. Taps are a good
point though. Perhaps fvalue_t's are better thought of just as the
'advanced' API for uncommon uses.

> I *do* see the definition of a string value changing in the future (to support embedded NULs, strings whose binary 
> representation is not valid in the encoding in question, etc.), so I don't want the current fvalue_t exposed as an 
> unchanging structure, but we're currently not guaranteeing source or binary compatibility for plugins or code using 
> libwireshark between major versions.

I expect we will never guarantee compatibility between major versions
- that's part of what major versions are for, after all.
___________________________________________________________________________
Sent via:    Wireshark-dev mailing list <wireshark-dev () wireshark org>
Archives:    http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
             mailto:wireshark-dev-request () wireshark org?subject=unsubscribe