On 8/24/07, Martin Mathieson [EMAIL PROTECTED] wrote:
Especially as its such a lower-layer protocol. I think the best thing may
be either:
- just revert my change, or maybe
- add something to the long text indicating that its 13 bits
OK, I did the 2nd option (i.e. don't use remove bitmask
I think it's much more easy to read the leading text and the value if
the details of the bitfields does not start the line. Ofcourse my
personal opinion, but mostly I do not care about the bits.
After committing this I wondered if it was worth it, i.e. it makes the
display less clean
Den 22. aug. 2007 kl. 14.43 skrev [EMAIL PROTECTED]:
http://anonsvn.wireshark.org/viewvc/viewvc.cgi?view=revrevision=22586
User: martinm
Date: 2007/08/22 02:43 PM
Log:
Show which bits 'fragment offset' comes from (I had to look it up :
( )
My personal opinion is that this bitfields
On Aug 22, 2007, at 3:19 PM, Stig Bjørlykke wrote:
My personal opinion is that this bitfields should be hidden in a
subtree, like this patch:
-proto_tree_add_uint(ip_tree, hf_ip_frag_offset, tvb, offset +
6, 2,
- (iph-ip_off IP_OFFSET)*8);
+tf =
Den 23. aug. 2007 kl. 00.34 skrev Guy Harris:
That's adding one more layer, with what amounts to a copy of the value
underneath it. Other than providing the raw offset, what advantages
does it offer? (There, I think, are other dissectors that have
bitfields that aren't in a subtree; if the
Hi,
So that is a general objection to the line-style, not so much providing
additional information. Sorry, but that gets a markdown in my book.
Sure, the style may be less ideal, but style consistency should take
precedence.
Thanx,
Jaap
Stig Bjørlykke wrote:
Den 23. aug. 2007 kl. 00.34
