ronnie sahlberg wrote:
> That would be an awful lot of work since we would need to modify (add
> registration of) all value_strings.
>
I only thought of the registration of the hf_ arrays, so this would
probably a single place to change.
I think this would already catch the vast majority of problems.
> Barring we could convince the coverity guys to add a check "make sure
> all arrays of the type value_string are terminated with {0,NULL}"
> but that wouldnt help out of tree dissectors nor can we rely on
> coverity being available to us forever.
>
Not an option in my eyes. I'm thinking about helping (newbie) developers
not needing to hunt down bugs hard to find.
If coverity comes in place, this is much too late for this purpose.
BTW: I couldn't find Ethereal/Wireshark on their project list recently?!?
>
> If we are making these changes we might also at the same time try to
> address the "linear search" property for the existing struct.
> While most value_strings are small there are some very very large
> ones that are used very frequently such as the SMB NT status code
> array.
>
> Binary trees have both good and bad properties. They would be good for
> managing these few very large value_strings efficiantly but since
> most of the value_strings are very small there would be a massive
> memory overhead for these small value_strings where a linear search
> would be quite sufficient.
>
> (we could change the accessor/search function for value strings to
> still keep it as a linear search array but everytime something has
> been looked up, we swap some pointers and let the "found" entry
> bubble upwards in the array to get it to automatically make sure at
> runtime that the frequently looked up entries are always near the
> start of the array and thus quick to find with a linear search)
>
>
I'm not sure on this, but I suppose the places where we have huge
value_strings are relatively rare.
Using a completely different (new) mechanism might be the way to go.
>
> Well an easy way to make sure all of them are properly terminated
> with a {0,NULL} is by using variadic macros.
> Unfortunately not standard until c99 but been part of GCC forever.
>
> #define VALUE_STRING(name, ...) \
> value_string_t name[] = { \
> __VA_ARGS__ \
> {0, NULL} \
> };
>
> VALUE_STRING(vs,
> {1, "foo"},
> {2, "bar"},
> )
>
>
> Does VC6 support variadic macros?
>
Sounds like a good approach.
I don't know if this is possible on VC6 (and other compilers we support)
and my current VC6 setup is out of business (I'm currently trying to
compile using VC 2005).
Maybe someone else can have a try?
Regards, ULFL
_______________________________________________
Wireshark-dev mailing list
[email protected]
http://www.wireshark.org/mailman/listinfo/wireshark-dev
