Wireshark · Ethereal-dev: Re: [Ethereal-dev] range preference type

[Guy Harris <gharris@xxxxxxxxx>]

Jeff Morriss wrote:

> When I first started working on it, the "varp" union had a "range_t *" 
> in it but as I went along I decided that the dissector API should just 
> be a string:  it's simpler and I couldn't think of any reason for the 
> dissector to have access to the actual range_t.

The dissector has that anyway, in effect - it can call 
"range_convert_str()".  In order to do anything useful with the range, 
it has to be converted to a range_t anyway.  I see it as cleaner to have 
that done by the preferences code rather than by the dissectors or by 
"prefs_range_foreach()".

> The upside is that we don't have to do any (one) of these:
>
>     - store both a range_t and a string in the preference
>     - store a string representation of the range in the range_t
>     - write a function to create a string given a range_t
>
> any one of which would be necessary in order to display and save the 
> preference.

The third of those makes sense to me - we do the same for uint 
preferences; we just don't need to supply our own routines for that, as 
we can just use "snprintf()".

> I don't have a strong preference for the string-based API--I just 
> thought it was cleaner.  Should I change it?

I find a range_t-based API cleaner - especially now that I've added code 
to prefs.c so that it checks whether integral preferences have valid 
values before fetching the preferences, and puts up an alert box 
reporting the error.  The same should be done for range values.