Wireshark-dev: Re: [Wireshark-dev] Regenerating packet-parlay.c
From: Luke Mewburn <luke@xxxxxxxxxxx>
Date: Sun, 3 May 2020 18:35:07 +1000
On 20-05-01 13:46, Jaap Keuter wrote: | On 5/1/20 12:02 PM, Luke Mewburn wrote: | > On 20-05-01 07:34, Jaap Keuter wrote: | > | | > | > On 1 May 2020, at 04:13, Luke Mewburn <luke@xxxxxxxxxxx> | > | > wrote: However, looking at the code some more, it appears | > | > that generally wireshark_gen.py generates code in the order | > | > the operations are defined; the exception (hah!) is the user | > | > exceptions. | > | > | > | > If I instead add at the top import collections and change | > | > get_exceptionList() from ex_hash = {} # holds a hash of | > | > unique exceptions. to ex_hash = collections.OrderedDict() | > | > # holds a hash of unique exceptions. | > | > | > | > This results in consistent generated code with both python | > | > 2.7 (CentOS 7) and python 3.7 (Fedora 31). | > | > | > | > I've also fixed a whitespace issue in the generated code by | > | > indenting the break in | > | > template_helper_switch_msgtype_default_end, so that it | > | > matches the epan/dissectors code and other default | > | > statements. | > | > | > | > | > | > Here's a patch with my suggested fixes. Or would you prefer | > | > a commit/pull request (etc)? | > | > | > | > | > | > regards, Luke. | > | > | > | | > | Hi Luke, | > | | > | That’s great, I didn’t have the opportunity yet to dig into | > | this. Nice that you compared Python 2.7 and 3.7 already. | > | I’ll pick this up and put it in with the other fixes I've | > | lined up, so you won’t have to push a change. I’ll credit you | > | in the commit :) | > | | > | Thanks, Jaap | | He Luke, | | Are you able to recreate the parlay dissector currently in the | repository with this. So far I haven't succeeded. | | Thanks, Jaap Yes, I regenerated the code using that patch to tools/wireshark_gen.py, and it builds fine across a couple of platforms. (BTW: I needed a separate build fix on CentOS 7 for packet-dof.c and I've pushed a change to review for that) I wrote a simple wrapper tool idl-regen (attached) to assist each regen from the idl, used with something like: $ ./idl-regen ../epan/dissectors/ mmccs.idl:120: Warning: Identifier 'EventType' clashes with CORBA 3 keyword 'eventtype' policy_data.idl:119: Warning: Anonymous sequences for recursive unions are deprecated. Use a forward declaration instead. policy_data.idl:123: Warning: Anonymous sequences for recursive unions are deprecated. Use a forward declaration instead. I get the same .c files generated from either: - CentOS 7, python 2.7.5, omniidl 4.2.0 - Fedora 31, python 3.7.6, omniidl 4.2.3 Three files get changes from git master: - packet-gias.c - packet-parlay.c - packet-tango.c The generated code for packet-gias.c and packet-tango.c differ to git master because of the following fix to idl2wrs that doesn't appear to have been rerun to regenerate those files: commit 443df93896 Author: Yannik Enss <Yannik.Enss@xxxxxxxxxxxxxxxxx> Date: 2019-05-29 14:20:42 +0200 idl2wrs: fix 'undeclared identifier' error the 'x_octetx' variables were removed a few years back, replace them with get_CDR_xxx() I8cf3410d8a152c834e7019f7d1d80de3798530c3 packet-parlay.c gets that above change as well as many other changes to generated code for /* User exception filters */, mostly in the ordering of the declarations and the list of array entries added to proto_register_giop_parlay() variable static hf_register_info hf[] As far as I can tell, the new packet-parlay.c has the same number of lines, just in different order. I manually applied a change of: disc_s_XXX = (gint32) u_octet4; /* save Enum Value discriminant and cast to gint32 */ to disc_s_XXX = (gint32) get_CDR_ulong(tvb,offset,stream_is_big_endian, boundary); /* save Enum Value discriminant and cast to gint32 */ and compared the regenerated file with that, they both still have same size and number of lines, and if I sort the lines in both the files are identical. (Of course, that doesn't compile... :) I tried doing some comparison of the generated object files but they differed too much, probably because of the reordering of the source lines, even though the hf[] array ends up with the same content in different order. I don't know how much more verification is required, however. It looks like in the past there have been changes to wireshark_gen.py and then regen of packet-parlay.c that reordered a lot of the content. For example, see commit c99bee9b5d on 2019-06-05. regards, Luke.
#!/bin/sh set -e prog=$(basename $0) if [ $# -lt 1 ]; then echo 1>&2 "usage: ${prog} outdir" exit 1 fi outdir="$1" if [ ! -d "${outdir}" ]; then echo 1>&2 "${prog}: no such directory '$outdir'" exit 1 fi omniidl -p ../tools -b wireshark_be coseventcomm.idl > "${outdir}"/packet-coseventcomm.c omniidl -p ../tools -b wireshark_be cosnaming.idl > "${outdir}"/packet-cosnaming.c omniidl -p ../tools -b wireshark_be tango.idl > "${outdir}"/packet-tango.c (cd gias && omniidl -p ../../tools -b wireshark_be gias.idl ) > "${outdir}"/packet-gias.c (cd parlay && omniidl -p ../../tools -b wireshark_be Parlay.idl ) > "${outdir}"/packet-parlay.c
Attachment:
pgpk1ITnyQCkK.pgp
Description: PGP signature
- Follow-Ups:
- Re: [Wireshark-dev] Regenerating packet-parlay.c
- From: Jaap Keuter
- Re: [Wireshark-dev] Regenerating packet-parlay.c
- References:
- Re: [Wireshark-dev] Regenerating packet-parlay.c
- From: Luke Mewburn
- Re: [Wireshark-dev] Regenerating packet-parlay.c
- From: Jaap Keuter
- Re: [Wireshark-dev] Regenerating packet-parlay.c
- From: Luke Mewburn
- Re: [Wireshark-dev] Regenerating packet-parlay.c
- From: Jaap Keuter
- Re: [Wireshark-dev] Regenerating packet-parlay.c
- Prev by Date: Re: [Wireshark-dev] Trying to decode a TLS 1.3 with null cipher
- Next by Date: Re: [Wireshark-dev] Regenerating packet-parlay.c
- Previous by thread: Re: [Wireshark-dev] Regenerating packet-parlay.c
- Next by thread: Re: [Wireshark-dev] Regenerating packet-parlay.c
- Index(es):