Re: [Wireshark-dev] Idle Thought - Compiling with C++
I am not sure about starting to make use of C++ features, but what I do find useful is maintaining a g++ build for a fairly large codebase I maintain. I have never even tried to run the resulting binary, but it catches certain errors that the C compiler does not. The most useful one is that C++ treats enums as proper types, so it catches assignments and comparisons that don't match the declared type. Also it is strict about pointer assignments, so you must add casts in many cases and I think this makes the code clearer. Martin Sent from Samsung tabletDonald White donald-wh...@cox.net wrote:On 2/9/2013 3:24 PM, Evan Huus wrote: On Sat, Feb 9, 2013 at 1:50 PM, Guy Harris g...@alum.mit.edu wrote: (Subject line changed to match what you presumably intended.) Yes, thank you. On Feb 9, 2013, at 6:41 AM, Evan Huus eapa...@gmail.com wrote: This just occurred to me as I was reading an article on GCC (which has recently migrated to using a C++ compiler, despite still being mostly written in C). I haven't given it a great deal of thought yet, but I figured I'd bring it up and see what general opinion was. At a first glance, building Wireshark with C++ compilers would give us two major benefits: ... - Built-in exceptions. This would be additional migration work, but it would permit us to drop a non-trivial amount of code that we currently own in order to do our own exceptions. Note that I'm not suggesting we start writing Wireshark in C++ (that's an entirely different debate), but that we could compile using C++ compilers, and then potentially sneak in a few C++ constructs where we used to roll our own. Presumably by start writing Wireshark in C++ you mean rearchitecting Wireshark as a C++ program, as once you've snuck in one C++ construct you're writing in C++. :-) Fair point. Note that some of Wireshark, i.e. the Qt GUI part, is already written in C++, and at least one third-party Wireshark plugin, i.e. the WSGD packet description language plugin: http://wsgd.free.fr is written in C++. I was aware of the QT GUI, but not of the extension. As far as I'm aware, Gerald's been doing the vast majority of the QT work, so I didn't want to take that as indicative of a general interest. See also http://hub.opensolaris.org/bin/view/User+Group+rs-osug/evan-adams The Old Man and the C Evan Adams Sun Microsystems Abstract You can't teach an old dog new tricks goes the old proverb. This is a story about a pack of old dogs (C programmers) and their odyssey of trying to learn new tricks (C++ programming). C++ is a large, complex language which can easily be abused, but also includes many features to help programmers more quickly write higher quality code. The TeamWare group consciously decided which C++ features to use and, just as importantly, which features not to use. We also incrementally adopted those features we chose to use. This resulted in a successful C++ experience. Very interesting article - I agree with most of it. I personally have some C++ experience (though less than I do pure C), but I have no idea what kind of experience with it others have. I do think that slowly and carefully adopting certain limited features of it would make our lives easier, though honestly the primary reason I suggested it was because of how fed up I am with MSVC :) 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 I haven't done any Wireshark development recently, and all of the dissectors I have written were proprietary and not submitted. That said, I have some experience with C to C++ transitions. Twice in my career, the team I was with was given the job of maintaining legacy products written in C (several 100K lines of code) to maintain and enhance. In both cases, our first step was to recompile with a C++ compiler. This was done as a quick and intense effort without introducing any C++ language features. We would just get the code to compile, link and pass its regression tests. Only later did we replace #defines with consts, macros with inline functions and such. I judged these efforts as being very beneficial in improving code quality. As fixing and enhancing could not stop, a small special team was assigned the work. They basically kept recompiling, transitioning and merging until they a had C++ equivalent code base. Then, the whole team switched to the new code base. Don ___ Sent via: Wireshark-dev mailing list wireshark-dev@wireshark.org Archives: http://www.wireshark.org/lists/wireshark-dev Unsubscribe:
Re: [Wireshark-dev] Idle Thought - Compiling with C++
Donald White wrote: That said, I have some experience with C to C++ transitions. Twice in my career, the team I was with was given the job of maintaining legacy products written in C (several 100K lines of code) to maintain and enhance. In both cases, our first step was to recompile with a C++ compiler. This was done as a quick and intense effort without introducing any C++ language features. We would just get the code to compile, link and pass its regression tests. Only later did we replace #defines with consts, macros with inline functions and such. I judged these efforts as being very beneficial in improving code quality. This is a reasonable approach for improving code quality. In an open source project like Wireshark, I think the challenge would be in specifying which C++ features/constructs would NOT be used. Having extensive experience with both C++ and C, I'd say that some of the most useful features in C++ didn't even exist in 1991 when that Old dogs, new tricks article was written. Specifically, I mean templates and the Standard Template Library (STL). That said, however and at the risk of stating the obvious, code written in C++ looks a lot different than C written in C++. For example, to me, the tvbuff.c and value_string.c files cry out for reimplementation as C++ classes, but to actually do such a reimplementation would very literally be a change to the core of Wireshark. If we were to use a C++ compiler as simply an enhanced C compiler, we'd have to figure out how to prevent submissions from including C++ constructs no approved by Wireshark coding guidelines. Ed ___ 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] Idle Thought - Compiling with C++
On Sun, Feb 10, 2013 at 9:06 AM, Ed Beroset bero...@mindspring.com wrote: Donald White wrote: That said, I have some experience with C to C++ transitions. Twice in my career, the team I was with was given the job of maintaining legacy products written in C (several 100K lines of code) to maintain and enhance. In both cases, our first step was to recompile with a C++ compiler. This was done as a quick and intense effort without introducing any C++ language features. We would just get the code to compile, link and pass its regression tests. Only later did we replace #defines with consts, macros with inline functions and such. I judged these efforts as being very beneficial in improving code quality. This is a reasonable approach for improving code quality. In an open source project like Wireshark, I think the challenge would be in specifying which C++ features/constructs would NOT be used. Having extensive experience with both C++ and C, I'd say that some of the most useful features in C++ didn't even exist in 1991 when that Old dogs, new tricks article was written. Specifically, I mean templates and the Standard Template Library (STL). That's a good point, actually. That said, however and at the risk of stating the obvious, code written in C++ looks a lot different than C written in C++. For example, to me, the tvbuff.c and value_string.c files cry out for reimplementation as C++ classes, but to actually do such a reimplementation would very literally be a change to the core of Wireshark. If we were to use a C++ compiler as simply an enhanced C compiler, we'd have to figure out how to prevent submissions from including C++ constructs no approved by Wireshark coding guidelines. I think the way to do this would be to start very small and slowly build up a white-list of C++ features and their accepted usages. Start with just things that are also part of later C standards (like variadic macros), and reject anything else C++. Only once we're comfortable with one thing would we start discussing what else we could safely add to the white-list. Wireshark has been doing just fine for nearly 15 years in pure C. I agree that parts of it cry out for classes and inheritance when I look at it with my C++ hat on, but they're not necessary, just useful. The way to do this (if we decide to) is definitely in a conservative manner. Evan P.S. Another thing to consider is that it's much easier (in general) for C++ to interface with C than vice versa. If we transition the core to use C++ constructs we're making it somewhat more difficult for people who know C but not C++ to write dissectors and plugins. ___ 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] Dissector for OID:1.2.826.0.1249.58.1.0 not implemented. Contact Wireshark developers if you want this supported
On 2/10/2013 7:37 AM, Rajinish Kumar wrote: Hello, am facing the below issue for a pcap trace captured from Ericsson node Dissector for OID:1.2.826.0.1249.58.1.0 not implemented. Contact Wireshark developers if you want this supported Please file an enhancement request at bugs.wireshark.org and, if possible, attach a small capture file containing the frame with the undissected OID. If necessary, you can mark the request private so that only the Wireshark core developers will be able to look at the capture file. Thanks ___ 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] buildbot failure in Wireshark 1.6 on OSX-10.5-PowerPC
It seems that some of the recent makefile changes (specifically the ones fixing dependencies for grammar-generated files) will need backporting to 1.6/1.8. I'm not sure how tied up those changes are to all the other recent build changes though, so they may need manual adjustment... On Sun, Feb 10, 2013 at 11:40 AM, buildbot-no-re...@wireshark.org wrote: The Buildbot has detected a new failure on builder OSX-10.5-PowerPC while building Wireshark 1.6. Full details are available at: http://buildbot.wireshark.org/trunk-1.6/builders/OSX-10.5-PowerPC/builds/234 Buildbot URL: http://buildbot.wireshark.org/trunk-1.6/ Buildslave for this Build: osx-10.5-ppc Build Reason: scheduler Build Source Stamp: 47604 Blamelist: gerald BUILD FAILED: failed compile sincerely, -The Buildbot ___ 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] Dissector for OID:1.2.826.0.1249.58.1.0 not implemented. Contact Wireshark developers if you want this supported
Rajinish Kumar skrev 2013-02-10 13:37: Hello, am facing the below issue for a pcap trace captured from Ericsson node Dissector for OID:1.2.826.0.1249.58.1.0 not implemented. Contact Wireshark developers if you want this supported -- BR Ravi I'm guessing that's a protocol extension Id (iso(1) member-body(2) gb(826) national(0) ericsson(1249) 58?1?) You need the vendors asn1 description of the parameter that goes with the extension to decode it. Best 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
