Re: [Wireshark-dev] [Wireshark-commits] rev 53135: /trunk/ui/gtk/ /trunk/ui/gtk/: main_menubar.c
On Nov 6, 2013, at 11:43 PM, alagou...@wireshark.org wrote: http://anonsvn.wireshark.org/viewvc/viewvc.cgi?view=revrevision=53135 User: alagoutte Date: 2013/11/07 07:43 AM Log: Add Edit Packet in Right Click Directory: /trunk/ui/gtk/ ChangesPath Action +18 -2 main_menubar.cModified By using gtk_dialog_get_content_area(), which isn't available in GTK+ prior to 2.14: https://developer.gnome.org/gtk3/stable/GtkDialog.html#gtk-dialog-get-content-area but the minimum GTK+ 2.x version is currently 2.12.0, and we have a buildbot (the 32-bit OS X buildbot, building for Leopard) that has a pre-2.14 version of GTK+, so the build on that buildbot is broken. ___ Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org Archives:http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] [Wireshark-commits] rev 53135: /trunk/ui/gtk/ /trunk/ui/gtk/: main_menubar.c
-Original Message- From: wireshark-dev-boun...@wireshark.org [mailto:wireshark-dev-boun...@wireshark.org] On Behalf Of Guy Harris Sent: den 7 november 2013 09:35 To: wireshark-dev@wireshark.org Subject: Re: [Wireshark-dev] [Wireshark-commits] rev 53135: /trunk/ui/gtk/ /trunk/ui/gtk/: main_menubar.c On Nov 6, 2013, at 11:43 PM, alagou...@wireshark.org wrote: http://anonsvn.wireshark.org/viewvc/viewvc.cgi?view=revrevision=53135 User: alagoutte Date: 2013/11/07 07:43 AM Log: Add Edit Packet in Right Click Directory: /trunk/ui/gtk/ ChangesPath Action +18 -2 main_menubar.cModified By using gtk_dialog_get_content_area(), which isn't available in GTK+ prior to 2.14: https://developer.gnome.org/gtk3/stable/GtkDialog.html#gtk-dialog-get-content-area but the minimum GTK+ 2.x version is currently 2.12.0, and we have a buildbot (the 32-bit OS X buildbot, building for Leopard) that has a pre-2.14 version of GTK+, so the build on that buildbot is broken. Earlier we had discussions about raising the minimum level to Glib 2.22 and GTK+ 2.18 http://wiki.wireshark.org/Development/Glib_Gtk_version_tracking Or should we do nothing pending the move to Qt keeping compatibility with older systems? Regards Anders ___ Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org Archives:http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe ___ Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org Archives:http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] [Wireshark-commits] rev 53135: /trunk/ui/gtk/ /trunk/ui/gtk/: main_menubar.c
Hi, On Thu, Nov 7, 2013 at 10:01 AM, Anders Broman anders.bro...@ericsson.comwrote: On Nov 6, 2013, at 11:43 PM, alagou...@wireshark.org wrote: http://anonsvn.wireshark.org/viewvc/viewvc.cgi?view=revrevision=5313 5 User: alagoutte Date: 2013/11/07 07:43 AM Log: Add Edit Packet in Right Click Directory: /trunk/ui/gtk/ ChangesPath Action +18 -2 main_menubar.cModified By using gtk_dialog_get_content_area(), which isn't available in GTK+ prior to 2.14: https://developer.gnome.org/gtk3/stable/GtkDialog.html#gtk-dialog-get-c ontent-area but the minimum GTK+ 2.x version is currently 2.12.0, and we have a buildbot (the 32-bit OS X buildbot, building for Leopard) that has a pre-2.14 version of GTK+, so the build on that buildbot is broken. Earlier we had discussions about raising the minimum level to Glib 2.22 and GTK+ 2.18 http://wiki.wireshark.org/Development/Glib_Gtk_version_tracking Or should we do nothing pending the move to Qt keeping compatibility with older systems? Regards Anders Actually the simplest is probably to make the feature = GTK+ 2.14 as it should be done for Qt anyway. Or use this fix ? http://www.gtkforums.com/viewtopic.php?p=6950sid=0f4888344b6b25474794610a41cc6514#p6950 Regards Anders ___ Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org Archives:http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] [Wireshark-commits] rev 53135: /trunk/ui/gtk/ /trunk/ui/gtk/: main_menubar.c
From: wireshark-dev-boun...@wireshark.org [mailto:wireshark-dev-boun...@wireshark.org] On Behalf Of Alexis La Goutte Sent: den 7 november 2013 10:05 To: Developer support list for Wireshark Subject: Re: [Wireshark-dev] [Wireshark-commits] rev 53135: /trunk/ui/gtk/ /trunk/ui/gtk/: main_menubar.c Hi, On Thu, Nov 7, 2013 at 10:01 AM, Anders Broman anders.bro...@ericsson.commailto:anders.bro...@ericsson.com wrote: On Nov 6, 2013, at 11:43 PM, alagou...@wireshark.orgmailto:alagou...@wireshark.org wrote: http://anonsvn.wireshark.org/viewvc/viewvc.cgi?view=revrevision=5313 5 User: alagoutte Date: 2013/11/07 07:43 AM Log: Add Edit Packet in Right Click Directory: /trunk/ui/gtk/ ChangesPath Action +18 -2 main_menubar.cModified By using gtk_dialog_get_content_area(), which isn't available in GTK+ prior to 2.14: https://developer.gnome.org/gtk3/stable/GtkDialog.html#gtk-dialog-get-c ontent-area but the minimum GTK+ 2.x version is currently 2.12.0, and we have a buildbot (the 32-bit OS X buildbot, building for Leopard) that has a pre-2.14 version of GTK+, so the build on that buildbot is broken. Earlier we had discussions about raising the minimum level to Glib 2.22 and GTK+ 2.18 http://wiki.wireshark.org/Development/Glib_Gtk_version_tracking Or should we do nothing pending the move to Qt keeping compatibility with older systems? Regards Anders Actually the simplest is probably to make the feature = GTK+ 2.14 as it should be done for Qt anyway. Or use this fix ? http://www.gtkforums.com/viewtopic.php?p=6950sid=0f4888344b6b25474794610a41cc6514#p6950 Sure, even better :) Regards Anders ___ Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org Archives:http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
[Wireshark-dev] Build wireshark-qt with Clang : -fPIC or -fPIE
Hi, When i try to build wireshark-qt with clang (and autotools) i have the following error message : dev:~/wireshark-clang/ui/qt$ make CXX accordion_frame.o In file included from /usr/include/qt5/QtGui/qwindowdefs.h:45:0, from /usr/include/qt5/QtWidgets/qwidget.h:45, from /usr/include/qt5/QtWidgets/qframe.h:45, from /usr/include/qt5/QtWidgets/QFrame:1, from accordion_frame.h:27, from accordion_frame.cpp:28: /usr/include/qt5/QtCore/qglobal.h:1079:4: error: #error You must build your code with position independent code if Qt was built with -reduce-relocations. Compile your code with -fPIC or -fPIE. # error You must build your code with position independent code if Qt was built with -reduce-relocations. \ ^ I fixed the issue with : --- a/configure.ac +++ b/configure.ac @@ -927,7 +927,7 @@ AC_WIRESHARK_LDFLAGS_CHECK([-Wl,--as-needed]) # in the address space to make attacks more difficult. # CFLAGS_before_pie=$CFLAGS -AC_WIRESHARK_COMPILER_FLAGS_CHECK(-fPIE, C) +AC_WIRESHARK_COMPILER_FLAGS_CHECK(-fPIE) if test x$CLFAGS != x$CFLAGS_before_pie then # Restore CFLAGS There is any reason to limit -fPIE to only C ? Regards, ___ Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org Archives:http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] Build wireshark-qt with Clang : -fPIC or -fPIE
On Thu, Nov 7, 2013 at 8:34 AM, Alexis La Goutte alexis.lagou...@gmail.com wrote: Hi, When i try to build wireshark-qt with clang (and autotools) i have the following error message : dev:~/wireshark-clang/ui/qt$ make CXX accordion_frame.o In file included from /usr/include/qt5/QtGui/qwindowdefs.h:45:0, from /usr/include/qt5/QtWidgets/qwidget.h:45, from /usr/include/qt5/QtWidgets/qframe.h:45, from /usr/include/qt5/QtWidgets/QFrame:1, from accordion_frame.h:27, from accordion_frame.cpp:28: /usr/include/qt5/QtCore/qglobal.h:1079:4: error: #error You must build your code with position independent code if Qt was built with -reduce-relocations. Compile your code with -fPIC or -fPIE. # error You must build your code with position independent code if Qt was built with -reduce-relocations. \ ^ I fixed the issue with : --- a/configure.ac +++ b/configure.ac @@ -927,7 +927,7 @@ AC_WIRESHARK_LDFLAGS_CHECK([-Wl,--as-needed]) # in the address space to make attacks more difficult. # CFLAGS_before_pie=$CFLAGS -AC_WIRESHARK_COMPILER_FLAGS_CHECK(-fPIE, C) +AC_WIRESHARK_COMPILER_FLAGS_CHECK(-fPIE) if test x$CLFAGS != x$CFLAGS_before_pie then # Restore CFLAGS There is any reason to limit -fPIE to only C ? Not that I know of. Note that $(PIE_CFLAGS) is already included in AM_CPPFLAGS in ui/qt/Makefile.am because that's what fixed the problem for me the first time a few months ago. It may have been an unnecessary and/or incorrect way of fixing the issue though. ___ Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org Archives:http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
[Wireshark-dev] Heuristic dissector priority
Hi I am currently implementing a generic dissector, which takes a predefined script and dissect payload. Pretty much in a way wsgd (wsgd.fr) does, but some features where lacking for me, and the integration into wireshark did not work for me either. One of the features of my solution is the possibility, to call a subdissector as part of the payload (therefore easing the implementation for some protocols like openSAFETY for instance). Currently I am thinking of adding the generic dissector to the heuristic filter lists. But I want to enable this for all possible protocols, and for this it needs to be the first heuristic dissector called. Basically the workflow would look like this: * Heuristic call to generic dissector * Dissector decides if it is allowed to dissect for this packet (method is different from wsgd) * If not, other heuristic dissectors may get a chance Now I have two possibilities: 1. Either rework the register_heuristic_dissector routine to automatically add the generic dissector allways at the first position 2. Rework dissector_try_heuristic and introduce a second list of heuristic dissectors (global, general, ... something like that), that will allways get precedence over list-specific heuristic dissectors. Basically I would favor the second approach, but before I send in a patch, I would like to get the opinion of everyone else. regards Roland ___ Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org Archives:http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] adding IRIG time and time of day
Message: 1 Date: Wed, 6 Nov 2013 13:12:04 -0800 From: Guy Harris g...@alum.mit.edu To: Developer support list for Wireshark wireshark-dev@wireshark.org Subject: Re: [Wireshark-dev] adding IRIG time and time of day Message-ID: a4378249-6d30-404f-8123-2fe8b845c...@alum.mit.edu Content-Type: text/plain; charset=iso-8859-1 On Nov 5, 2013, at 3:22 PM, John Dill john.d...@greenfieldeng.com wrote: They provided a set of sample driver programs that used the board's internal clock to timestamp packets, starting from 0. There was no sample (back then, there may be now) that demonstrated how to use the IRIG time signal from the board to synchronize the packet stream, or to populate the packet time with an Unix epoch timestamp (their API did at least document how to query the board for an IRIG time in seconds). So they didn't provide code to even time stamp packets with IRIG-derived time stamps, much less with Unix-epoch time stamps? Correct. Condor Engineering (bought by GE) also provided a modified version of Ethereal (or Wireshark) that attempts to handle some of the extensions that AFDX provided in a different graphical representation. It was difficult to understand and impractical to use for our needs. Could you get the source code to their modifications? (If not, they've violated the GPL, and lawyers can be sent after them to force them to provide the source code.) That might be interesting. They provide three headers: cpcap.h, CnicStructures.h, and version.h, and a library that you link against. The version that I have have a copyright license from Condor Engineering. From the look of the header file, most of the interface does not mimic pcap per se except for the pcap_compile related stuff. The source code never came with the distribution, and I never bothered to ask for it, so it's unclear how much is a wrapper around pcap and what's not. The other data streams (ARINC-429 and MIL-STD-1553 were timestamped using IRIG-B without the year, and their BusTools applications that provided graphical introspection of the data did not support Unix Epoch time format as an option. I decided to synchronize the packet stream to the IRIG-B so that all three bus modalities were synchronized to that same format. At that time, I was not very familiar with the pcap-ng standard and made that decision based on my group's local needs. OK, so it sounds as if you had to (as per the first paragraph above) write your own code to combine the board's internal clock value and the IRIG time value somehow to generate a fractions of a second since the beginning of the current year time stamp for packets. Combining that with the current year would have been preferable, but what's done is done. That's correct. I'm not sure if there's a good way to resolve the issue. Changing the MIL-STD-1553 and ARINC-429 timestamps to Unix Epoch would break their compatibility with the GE tools, and we'd have to adapt our other software tools to handle mixed time formats. There's several years worth of data that may or may not be politcally difficult to justify retroactively applying the Unix epoch just to make the capture files standard compliant. So, *IF* you know what year a capture was started, you could convert the time stamps in libwireshark, and present seconds-and-nanoseconds-since-the-Epoch time stamps to Wireshark/TShark/etc., as those programs expect. I can find the year based on either the last modification timestamp of in the file's properties, or using the date substring in the packet dump filename as well. The packet dump files all have an automatically generated filename with a standard naming convention. I suppose it's possible to analyze the filename format on Open and branch into a special case that resolves the time difference (in a patch I'd maintain). If you know what year a given capture was started, one option might be to: add a special API to libwireshark to specify a starting year for an open capture file (zero would mean this file has valid time stamps, no conversion is necessary); have the pcap-ng reader use that information to convert fractions-of-a-second-since-the-beginning-of-the-year to seconds-and-nanoseconds-since-the-Epoch (doing this means keeping a table of frame offsets in the file and time offsets, so that random access works, and watching for a wrap-around in the time stamps and treating that as a switch to a new year, unless you don't need to support captures that start on or before December 31 and end on or after January 1 of the next year); use the current trunk version of Wireshark, which has an option to display time stamps as /DOY HH:MM:SS, or apply the change for that: http://anonsvn.wireshark.org/viewvc?revision=53114view=revision https://www.greenfieldeng.com/exchweb/bin/redir.asp?URL=http://anonsvn.wireshark.org/viewvc?revision=53114%26view=revision to your version (not all of the changes are necessary for
[Wireshark-dev] Add data parameter to tcp_dissect_pdus?
Should tcp_dissect_pdus() add a data parameter to allow private data that was passed to a dissector running over TCP to be used by the dissector itself? I debated this when removing the pinfo-private data used to pass struct tcpinfo data in r53036. The only current dissector that uses tcp_dissect_pdus() + the private data from TCP is the NDMP dissector, so I didn't think it was worth it and just used p_add_proto_data(). I didn't add p_add_proto_data() in enough places and caused bugs 9393-9394 which is what opened this discussion. Now I'm leaning more towards having the data parameter. Curious as to other opinions. Michael ___ Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org Archives:http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] Add data parameter to tcp_dissect_pdus?
On Thu, Nov 7, 2013 at 12:33 PM, mman...@netscape.net wrote: Should tcp_dissect_pdus() add a data parameter to allow private data that was passed to a dissector running over TCP to be used by the dissector itself? I debated this when removing the pinfo-private data used to pass struct tcpinfo data in r53036. The only current dissector that uses tcp_dissect_pdus() + the private data from TCP is the NDMP dissector, so I didn't think it was worth it and just used p_add_proto_data(). I didn't add p_add_proto_data() in enough places and caused bugs 9393-9394 which is what opened this discussion. Now I'm leaning more towards having the data parameter. Curious as to other opinions. I think it makes sense to add a data parameter to tcp_dissect_pdus. I certainly can't see why it would cause problems. Evan ___ Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org Archives:http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] Add data parameter to tcp_dissect_pdus?
On Nov 7, 2013, at 10:28 AM, Evan Huus eapa...@gmail.com wrote: I think it makes sense to add a data parameter to tcp_dissect_pdus. I certainly can't see why it would cause problems. +1 ___ Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org Archives:http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] [Wireshark-commits] rev 53146: /trunk/epan/ /trunk/epan/dissectors/: packet-2dparityfec.c packet-acap.c packet-bitcoin.c packet-data.c packet-daytime.c packet-dbus.c packet-fcdns.c
On Nov 7, 2013, at 3:14 PM, darkja...@wireshark.org wrote: http://anonsvn.wireshark.org/viewvc/viewvc.cgi?view=revrevision=53146 User: darkjames Date: 2013/11/07 08:14 PM Log: Add infrastructure for section-initializing protocol hfis (without array). Looks cool. How is this going to work exactly (or will it be obvious in later commits)? Cheers, Evan configure implementation later. Directory: /trunk/epan/dissectors/ ChangesPathAction +2 -0 packet-2dparityfec.cModified +2 -0 packet-acap.c Modified +2 -0 packet-bitcoin.cModified +2 -0 packet-data.c Modified +2 -0 packet-daytime.cModified +2 -0 packet-dbus.c Modified +2 -1 packet-fcdns.c Modified +2 -0 packet-gadu-gadu.c Modified +2 -0 packet-hpext.c Modified +2 -0 packet-http-urlencoded.cModified +2 -0 packet-image-gif.c Modified (15 files not shown) ___ Sent via:Wireshark-commits mailing list wireshark-comm...@wireshark.org Archives:http://www.wireshark.org/lists/wireshark-commits Unsubscribe: https://wireshark.org/mailman/options/wireshark-commits mailto:wireshark-commits-requ...@wireshark.org?subject=unsubscribe ___ Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org Archives:http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] [Wireshark-commits] rev 53146: /trunk/epan/ /trunk/epan/dissectors/: packet-2dparityfec.c packet-acap.c packet-bitcoin.c packet-data.c packet-daytime.c packet-dbus.c packet-fcdns.c
On Thu, Nov 07, 2013 at 08:14:20PM +, darkja...@wireshark.org wrote: http://anonsvn.wireshark.org/viewvc/viewvc.cgi?view=revrevision=53146 User: darkjames Date: 2013/11/07 08:14 PM Log: Add infrastructure for section-initializing protocol hfis (without array). Nice! configure implementation later. Why make this a configure option instead of just setting it? Ciao Jörg -- Joerg Mayer jma...@loplof.de We are stuck with technology when what we really want is just stuff that works. Some say that should read Microsoft instead of technology. ___ Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org Archives:http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
[Wireshark-dev] Git mirror issues
A while back Erwin Rol noticed that tags weren't showing up in the git mirror[1]. I finally had a chance to look into the issue in detail and as it turns out some transactions were failing due to a stale lock file. After cleaning up the lock file and running 'git fsck' the missing tags have appeared. I created a new SVN→Git export from scratch for validation. It is available at http://code.wireshark.org/git/wireshark-rebase-2013-11-07 Its history differs quite a bit from the main git mirror, but this appears to be due to changes in the identity map (SVN userernames to Git email addresses) which were made over the past year. The file and directory contents appear to be the same. I compared a fresh SVN checkout with a clone of the old and new git mirrors and they were all identical except for the VCS metainformation. It would be nice to replace the current mirror with a fresh export but it looks like that might cause problems. If I run the following: git clone http://code.wireshark.org/git/wireshark ws-git-test cd ws-git-test git remote set-url origin \ http://code.wireshark.org/git/wireshark-rebase-2013-11-07 Then 'git pull' produces a lot of errors but 'git pull --rebase' seems to work fine. If I *did* freshen the git mirror, would having to rebase cause any undue problems for any git users? BTW, I'm still hoping to migrate to Git at some point, probably after Gerrit 2.8 is released. It adds a few useful new features including easier backporting and a GitHub integration plugin. In the meantime I'll see if I can add checks to detect any more mirror failures. [1] http://www.wireshark.org/lists/wireshark-dev/201309/msg00244.html ___ Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org Archives:http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] [Wireshark-commits] rev 53146: /trunk/epan/ /trunk/epan/dissectors/: packet-2dparityfec.c packet-acap.c packet-bitcoin.c packet-data.c packet-daytime.c packet-dbus.c packet-fcdns.c
On Thu, Nov 07, 2013 at 10:43:26PM +0100, Jakub Zawadzki wrote: On Thu, Nov 07, 2013 at 09:52:19PM +0100, Joerg Mayer wrote: On Thu, Nov 07, 2013 at 08:14:20PM +, darkja...@wireshark.org wrote: http://anonsvn.wireshark.org/viewvc/viewvc.cgi?view=revrevision=53146 User: darkjames Date: 2013/11/07 08:14 PM Log: Add infrastructure for section-initializing protocol hfis (without array). Nice! configure implementation later. Why make this a configure option instead of just setting it? I'd love to say it works on every platform, but unfortunetly it's not true even on Linux. After r53150 it works with GCC, at least on my Linux ;-) ___ Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org Archives:http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] [Wireshark-commits] rev 53146: /trunk/epan/ /trunk/epan/dissectors/: packet-2dparityfec.c packet-acap.c packet-bitcoin.c packet-data.c packet-daytime.c packet-dbus.c packet-fcdns.c
On Fri, Nov 08, 2013 at 01:03:47AM +0100, Jakub Zawadzki wrote: After r53150 it works with GCC, at least on my Linux ;-) And after another commit it also works on my system (32-bit Linux with GCC 4.8.2), so I decided to make it easier to play with this. Turns out my mint dissector had an unused element ;-) Hopefully I'll be able to test on windows tomorrow so if a few more tests turn out good results the old code could be removed. Ciao jörg -- Joerg Mayer jma...@loplof.de We are stuck with technology when what we really want is just stuff that works. Some say that should read Microsoft instead of technology. ___ Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org Archives:http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] [Wireshark-commits] rev 53146: /trunk/epan/ /trunk/epan/dissectors/: packet-2dparityfec.c packet-acap.c packet-bitcoin.c packet-data.c packet-daytime.c packet-dbus.c packet-fcdns.c
On Fri, Nov 08, 2013 at 01:27:40AM +0100, Joerg Mayer wrote:
On Fri, Nov 08, 2013 at 01:03:47AM +0100, Jakub Zawadzki wrote:
After r53150 it works with GCC, at least on my Linux ;-)
And after another commit it also works on my system (32-bit Linux with GCC
4.8.2),
so I decided to make it easier to play with this.
Turns out my mint dissector had an unused element ;-)
Yeah, no longer need for checkhf.pl (which in fact doesn't work with new style
dissectors).
Hopefully I'll be able to test on windows tomorrow so if a few more tests
turn out good results the old code could be removed.
Windows MSVC doesn't support __attribute__((section)) it has their own
way [1]. It could work with mingw/cygwin.
Even if we implement it for Windows, we can't remove hfi array
completely. There might be systems on which it won't work.
It's good opt-in (binary can be smaller by about 1-2 MB, which will
give us minimally faster startup), but not portable.
We could not emulate arrays using section, but write it explicit (100%
portable!):
enum {
HF_FOO = 0,
HF_BAR
};
struct header_field_info proto_hfi[] = {
{ field_foo },
{ field_bar }
};
proto_tree_add_item( proto_hfi[HF_FOO] );
proto_tree_add_item( proto_hfi[HF_BAR] );
but to make maintaince of assigning good index to hfi easier, we'd need C99:
struct header_field_info proto_hfi[] = {
[HF_FOO] = { field_foo },
[HF_BAR] = { field_bar }
};
Which is not supported at least in MSVC, anyway seperate variable for each hf
looks IMHO nicer.
[1]
http://stackoverflow.com/questions/3808053/how-to-get-a-pointer-to-a-binary-section-in-msvc
___
Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org
Archives:http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
