On 10/19/2011 7:46 PM, Guy Harris wrote:
FT_PROTOCOL Not yet fixed: Should be ???
ENC_NA. It's like FT_NONE.
Q: Does it make any sense for an entry in hf[] in a dissector to have a
field type of FT_PROTOCOL ? (e.g., packet-extreme.c)
I just noticed that there are a few cases like thi
On Oct 19, 2011, at 4:28 PM, Bill Meier wrote:
> No fixes required:
> FT_RELATIVE_TIME
> FT_FRAMENUM
> FT_PCRE
...because they're currently not supported by proto_tree_add_item().
FT_FRAMENUM never will be, and FT_PCRE is, I think, a type used only in filter
expressions (a field cannot
On 10/4/2011 1:53 PM, Bill Meier wrote:
I propose to use a perl script to automate as much as reasonable the
replacement of TRUE/FALSE in the encoding parameter of the
proto_tree_add_item() calls in dissectors as follows:
OK: To summarize: (Note ??? at end)
Fixes done (when possible):
FT_
Anders Broman writes:
> > Should we use ENC_NA here too to prevent confusion?
> My preference is the opposite use ENC_BIG_ENDIAN as that is the
> "natural" encoding for the
> protocol and ENC_BIG_ENDIAN is less confusing in my opinion.
For what it's worth, I agree with Anders here. I tend to
Stephen Fisher skrev 2011-10-19 19:27:
On Tue, Oct 04, 2011 at 03:07:43PM -0400, Tony Trinh wrote:
The comment for ENC_NA:
/*
* For protocols (FT_PROTOCOL), aggregate items with subtrees (FT_NONE),
* opaque byte-array fields (FT_BYTES), and other fields where there
* is no choice of enco
On Tue, Oct 04, 2011 at 03:07:43PM -0400, Tony Trinh wrote:
> The comment for ENC_NA:
>
> /*
> * For protocols (FT_PROTOCOL), aggregate items with subtrees (FT_NONE),
> * opaque byte-array fields (FT_BYTES), and other fields where there
> * is no choice of encoding (either because it's "just a
On 10/18/2011 9:34 AM, Bill Meier wrote:
On 10/18/2011 9:13 AM, Jeff Morriss wrote:
morr...@wireshark.org wrote:
Directory: /trunk/epan/dissectors/
Changes Path Action
+13 -6 packet-pcep.c Modified
Bill,
Just FYI this file doesn't appear to have been caught by your
encoding-fixing script. L
