[Jeff Morriss <jeff.morriss@xxxxxxxxxxx>]

Guy Harris wrote:

> Jeff Morriss wrote:
>
> > Fortunately, I did (have enough time):  see the attached patch which 
> > implements the new preference type and changes the TCAP dissector to 
> > use it.
>
>
> Hmm.  It currently hides from the subdissector the rangeness, it 
> appears.  Should the "varp" union in "struct preference" include a 
> "range_t *", with "prefs_register_range_preference()" supplying a 
> pointer to a "range_t" value?

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.  Come to think of it, 
though, the dissectors probably do need an equivalent to 
'value_is_in_range()' which I guess is the downside to that API: it 
requires wrappers and extra calls to 'range_convert_str()'.

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.

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