On Tue, Apr 25, 2000 at 06:52:03PM +0100, Ben Fowler wrote:
>
> Obviously this is not right. The next question is would you be prepared
> to have code as trite looking as
>
> enum ... = (
> ...
> DISPLAY_WIDTH_1 = 1,
> DISPLAY_WIDTH_2,
> DISPLAY_WIDTH_3,
> DISPLAY_WIDTH_4,
> DISPLAY_WIDTH_5,
> ...
> );
Okay. I had to think twice, trying to consider if I really wanted
macros that have the value that they define as part of their name. It
seems unnecessarily redundant. However, I agree that seeing DISPLAY_*
in that field in the registration array will improve readability.
> I understand that. My request which does mean more work and will take up
> more space for most people would be have a separate, smaller field for the
> tooltip, not to enlarge the blurb field.
I'm starting to wonder if our current method of protocol/field registration
isn't exactly what we need. It almost seems that we need a separate file, with
a syntax more readable than a C array, which describes the protocol/field,
including blurb and tooltip. This human-readable file is parsed and two
separate C files are made from it, one with just the data necessary for
dissecting, and one with the strings. Tethereal needs just the dissection
info, while Ethereal needs both.
In fact, now that I've said that, perhaps 3 files should be generated
from this human-readable data file. I'd split the lengthy blurb data into
a file separate from the tool tips. The tool tips will have to be loaded into
memory with the Ethereal executable, so they should be linked into the
executable. But the blurb data can be loaded on demand, since the user
may never use it (i.e., once we have a filter GUI). The blurbs can be put
into a DBM file and loaded when needed.
This past weekend I toyed with some ideas for re-implementing the NCP dissector.
I created some classes in Python to represent field types and such, and then
created my tables of field information as Python code. Step 2 is to then have the
python code create C code. The field tables came out looking very readable. I'm not
saying to use python for this "human-readable format", but just saying that
things like this can be done. I know Richard created a lot of the SMB code this way,
using Perl. But here I'm focusing only on the registration arrays, not the code itself.
--gilbert
