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: Unless there are concerns, there will be one last massive change
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
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
Anders Broman a.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
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):
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/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
I'll hold off doing any changes until tomorrow to wait for any comments.
Use ENC_ASCII. I suspect the majority of protocols currently available
is so old, that they don't use anything more modern. And our users will
tell us if ENC_ASCII is wrong for some protocols and we can fix them
On 10/12/2011 3:30 PM, Bill Meier wrote:
Based upon the comments:
I propose to do the following for
the FT_STRING, FT_STRINGZ, FT_UINT_STRING encoding parameter:
Conversions:
1. For other than FT_UINT_STRING, always use ENC_NA
(replacing any existing True/1/FALSE/0
Re:
Should these functions be modified to take an encoding argument instead of a
little_endian argument, then the Perl script run on them as well to convert
TRUE/FALSE to ENC_LITTLE_ENDIAN/ENC_BIG_ENDIAN?
I think so.
tvb_fake_unicode()
; no remaining usage in Wireshark;leave as
On 10/10/2011 2:44 PM, Bill Meier wrote:
For FT_STRING..., rather than cluttering up the encoding arg with
ENC_NA, I would be sightly inclined to specify endianness only where
relevant.
For FT_UINT_STRING obviously ENC_[BIG|LITTLE]_... would be needed for all.
However, I can understand the
On Oct 12, 2011, at 1:16 PM, Guy Harris wrote:
[...elided...] I *might* be inclined to go with ENC_ASCII as the first step
even though it'd require more changes (e.g., to protocols where the encoding
is UTF-8).
Or, to put it another way: going with ENC_ASCII is the conservative solution,
On Oct 10, 2011, at 11:41 AM, Bill Meier wrote:
-- packet-gmhdr.c
Presumably ENC_TIME_TIMESPEC|ENC_BIG_ENDIAN, as:
1) presumably they knew what they were doing, and their dissector
works, and ENC_TIME_TIMESPEC is 0, as is ENC_BIG_ENDIAN, so FALSE =
ENC_TIME_TIMESPEC|ENC_BIG_ENDIAN
On 10/4/2011 2:45 PM, Guy Harris wrote:
Presumably all the uses of
proto_tree_add_item() and the like for FT_ABSOLUTE_TIME values
already have the encoding specified and already use
ENC_LITTLE_ENDIAN/ENC_BIG_ENDIAN.
Not quite all :)See below.
On 10/4/2011 2:45 PM, Guy Harris wrote:
... FT_STRING, FT_STRINGZ, and FT_UINT_STRING, for which an
encoding should also be supplied.
The endianness is irrelevant for ENC_UTF_8, ENC_ASCII, and
ENC_EBCDIC.
In the future, there will be ENC_UTF_16 and possibly ENC_UCS_2, for
which the
On Oct 10, 2011, at 11:44 AM, Bill Meier wrote:
In any case, no matter what is decided, changes will be needed for FT_STRING
etc.
Is it OK to just change all the instances with no character encoding to
ENC_ASCII (with or without ENC_NA) ?
That, or ENC_UTF_8. I suspect most new
Bill Meier wmeier@... writes:
In this case, given the specifics, I found it fairly simple to do what I
needed in Perl.
Should these functions be modified to take an encoding argument instead of a
little_endian argument, then the Perl script run on them as well to convert
TRUE/FALSE to
Chris Maynard skrev 2011-10-05 20:36:
Bill Meierwmeier@... writes:
In this case, given the specifics, I found it fairly simple to do what I
needed in Perl.
Should these functions be modified to take an encoding argument instead of a
little_endian argument, then the Perl script run on them as
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:
First step:
For hf[] entries with type
FT_NONE
FT_BYTES
FT_IPV6
FT_IPXNET
FT_UID
convert the
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:
sounds good, but may be difficult to write. Because you would need to
write a parser for C function calls in
On Oct 4, 2011, at 10:53 AM, Bill Meier wrote:
For the next step is it simply a case of replacing the remaining TRUE/FALSE
encoding parameter by ENC_LITTLE_ENDIAN/ENC_BIG_ENDIAN ?
Except for FT_STRING, FT_STRINGZ, and FT_UINT_STRING, for which an encoding
should also be supplied.
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:
First step:
For hf[] entries with type
FT_NONE
FT_BYTES
FT_IPV6
FT_IPXNET
One thing I don't quite understand: In a number of the dissectors why do
proto_tree_add_item() encoding parameters for hf items with type FT_STRING
have ENC_ASCII *and* ENC_LITTLE_ENDIAN|ENC_BIG_**ENDIAN ?
Shouldn't this be ENC_ASCII | ENC_NA in this case ?
The comment for ENC_NA:
/*
*
Dirk Jagdmann 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:
sounds good, but may be difficult to write. Because you would need to
write a parser for C
On 10/4/2011 4:08 PM, Jeff Morriss wrote:
I had a fair amount of luck with the (currently not run)
checkAPIsCalledWithTvbGetPtr() function in checkAPIs.pl . It
definitely is not 100%, but it served my purposes well. It avoids
dealing with parenthesis by assuming the only semi-colon it will find
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:
First step:
For hf[] entries with type
FT_NONE
FT_BYTES
FT_IPV6
FT_IPXNET
On Oct 4, 2011, at 10:53 AM, 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:
First step:
For hf[] entries with type
FT_NONE
On 10/4/2011 4:48 PM, Guy Harris wrote:
On Oct 4, 2011, at 10:53 AM, 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:
First step:
For hf[]
On 10/4/2011 2:49 PM, David Young wrote:
On Tue, Oct 04, 2011 at 11:38:48AM -0700, Dirk Jagdmann wrote:
Sounds like a perfect job for Coccinelle,http://coccinelle.lip6.fr/.
Looks like an interesting tool; I'll have to spend a little time reading
the documentation. Thanks for the reference
29 matches
Mail list logo
