> At present, it seems that ethereal regards each and every flag
> as a single stand alone boolean which is on or off (having appropriate
> labels in a TRUE/FALSE structure) and displayed left justified.
That's certainly how I think of flag bits within fields (i.e., I
deliberately wrote the bitfield-dissection code to function the way it
currently does).
> This is despite the fact that throughout the code we have comments
> in the form 'FLAGS field' recognising that flags come in bunches,
> and programmers are quite used to hardware concepts such as a
> FLAGS Word, Half-Word or Byte.
...which is why we also display the entire field in which the various
bitfields occur.
We don't think of flag bits as being any different from any other sort
of bitfield.
> For my part, I would like flags to be displayed concisely in their
> location within a flags field, videlicet:
>
> Header Flags
> c... .GTr
> .000 1... = PDU Type: Invoke
> .... .11. = Trailer flags: Packet re-assembly not supported
>
> in which
> bit 0 is a flag C = Continuation present, c = continuation absent
> bits 1-4 are a bit field holding the type of the packet
> bit 5 is the Group Trailer [G/g] flag
> bit 6 is the Transmission Trailer [T/t] flag
> bit 7 is the Re-transmission indicator [R/r]
This appears to differ from the current scheme only in that
1) it doesn't display the state of the "c" bit, which I would
consider a deficiency - I'd want it to be more like
Header Flags
c... .GTr
0... .... = Continuation: absent
.000 1... = PDU Type: Invoke
.... .11. = Trailer flags: Packet re-assembly not supported
.... ...0 = Retransmission: no retransmission
there is no guarantee that the mere appearance of a "c" or "C"
there will necessarily mean anything to the user, so I *REALLY*
want to have a full textual description of all fields, including
one-bit Boolean fields, not just a concise summary like the
"c... .GTr" line;
2) it doesn't show the value of the entire field (0x0E);
3) it has the summary line displaying letters for the one-bit
Boolean bitfields, which would be OK with me *as long as it
didn't replace the detailed description of those fields*.
> Note that bits 5 and 6 have a special meaning when both are set, that
> the implementation does not support packet fragmentation/re-assembly
> at all, and these bits are available for interpretation as bit field.
...which means it's a special case, unlike, say, the flag bits in a TCP
flags field, where they're all completely independent. That may be a cas
> If I were to submit a patch implementing a type FT_FLAGS_BYTE, would
> this be accepted. It would be in competition with the existing FT_BOOLEAN
> type but would not supplant it.
What would that type do?
The "Header Flags" field (which, the name nonwithstanding, is not all
flags, as the PDU Type field isn't a flag bit) wouldn't in the current
scheme, be an FT_BOOLEAN field, so presumably the field in its entirety
wouldn't be FT_FLAGS_BYTE (BYTE would be inappropriate in any case if it
contained more than 8 bits, unless you're running on, say, a PDP-10
:-)).
If the Continuation, Group Trailer, Transmission Trailer, and
Re-transmission indicator one-bit Boolean bitfields would have that
type, both the "S" in "FLAGS" and the "BYTE" would be inappropriate, as
each of them is just one flag, and they have only one bit.
