Re: [Wireshark-dev] [Wireshark-commits] rev 51854: /trunk/ /trunk/doc/: editcap.pod /trunk/: editcap.c

2013-09-08 Thread Maynard, Chris
Please note that we actually have up to 2 regions that can be chopped in a single pass by using multiple -C options (1 region specified by the positive length and the other region specified by the negative length). However, one must ensure that the region specified by the positive length does n

Re: [Wireshark-dev] [Wireshark-commits] rev 51844: /trunk/epan/ /trunk/epan/: expert.c expert.h proto.c /trunk/epan/wslua/: init_wslua.c wslua_tree.c

2013-09-08 Thread mmann78
The problem is that all "external" expert APIs end up calling static functions within expert.c and I really don't want to have that much copy/paste for something that will hopefully be removed shortly. Since the word is now out through the -commit and -dev mailing lists, people should conside

Re: [Wireshark-dev] [Wireshark-commits] rev 51855: /trunk/ /trunk/: capture-pcap-util-unix.c

2013-09-08 Thread Guy Harris
On Sep 8, 2013, at 6:23 PM, wme...@wireshark.org wrote: > http://anonsvn.wireshark.org/viewvc/viewvc.cgi?view=rev&revision=51855 > > User: wmeier > Date: 2013/09/08 06:23 PM > > Log: > Revert #51843: Build fails on OSX-10.5-x8 Note that pcap.h is not always in /usr/include/pcap; I created tha

Re: [Wireshark-dev] [Wireshark-commits] rev 51845: /trunk/ /trunk/doc/: editcap.pod /trunk/docbook/: release-notes.asciidoc /trunk/: editcap.c

2013-09-08 Thread Evan Huus
Ah, I was thinking of bug 8511, which isn't quite the same (though close enough to twig my memory). This might make it easier to fix though? I've never dug into editcap in any detail. https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=8511 On 2013-09-08, at 5:41 PM, "Maynard, Chris" wrote:

Re: [Wireshark-dev] [Wireshark-commits] rev 51845: /trunk/ /trunk/doc/: editcap.pod /trunk/docbook/: release-notes.asciidoc /trunk/: editcap.c

2013-09-08 Thread Maynard, Chris
Hmm, I couldn't find one. There were some editcap-related bugs open, but I didn't see one specifically for this feature or even where this feature would resolve the bug by luck. Maybe I'm missing it too though. I added this as a way to help simplify the steps I outlined in my answer to http:/

Re: [Wireshark-dev] -Werror for Qt code

2013-09-08 Thread David Arnold
On 09/09/2013, at 5:22 AM, Guy Harris wrote: > And disable the "warn me if a 64-bit value is being shortened to 32 bits" > warning, because Qt 5 *itself* has code in headers that doesn't cast away > those warnings (or fix them if they're real issues). Or (on GCC platforms) include them using -i

Re: [Wireshark-dev] [Wireshark-commits] rev 51845: /trunk/ /trunk/doc/: editcap.pod /trunk/docbook/: release-notes.asciidoc /trunk/: editcap.c

2013-09-08 Thread Evan Huus
IIRC there is (or was) a ticket open for this feature, if somebody remembers which one that would be nice, or I will try and learn bugzilla's search function again :) On 2013-09-08, at 8:29 PM, cmayn...@wireshark.org wrote: > http://anonsvn.wireshark.org/viewvc/viewvc.cgi?view=rev&revision=5184

Re: [Wireshark-dev] -Werror for Qt code

2013-09-08 Thread Evan Huus
On 2013-09-08, at 3:22 PM, Guy Harris wrote: > > On Sep 8, 2013, at 8:05 AM, eapa...@wireshark.org wrote: > >> Fix "seq_base could be used unitialized" warning. We should probably enable >> -Werror for the qt code... > > And disable the "warn me if a 64-bit value is being shortened to 32 bits"

Re: [Wireshark-dev] [Wireshark-commits] rev 51844: /trunk/epan/ /trunk/epan/: expert.c expert.h proto.c /trunk/epan/wslua/: init_wslua.c wslua_tree.c

2013-09-08 Thread Evan Huus
Excellent :) Suggest simply move the prototype for _internal into the two C files that use it, so it's not even available for anyone who shouldn't have it? Kind of yucky though, it's true... On 2013-09-08, at 7:32 PM, mm...@wireshark.org wrote: > http://anonsvn.wireshark.org/viewvc/viewvc.cgi?

[Wireshark-dev] -Werror for Qt code

2013-09-08 Thread Guy Harris
On Sep 8, 2013, at 8:05 AM, eapa...@wireshark.org wrote: > Fix "seq_base could be used unitialized" warning. We should probably enable > -Werror for the qt code... And disable the "warn me if a 64-bit value is being shortened to 32 bits" warning, because Qt 5 *itself* has code in headers that d