Re: [Wireshark-dev] Prevent compiler warnings by using stop on warnings/treat warnings as errors compiler option?
On Thu, Mar 22, 2007 at 04:08:36PM -0700, Stephen Fisher wrote: On Wed, Mar 21, 2007 at 05:46:50PM -0700, Stephen Fisher wrote: I've found a way around this issue and have introduced it into the same places in my tree on Unix as Ulf has on Windows so far. It's a variable setup by the configure script that is tested in each directory's Makefile.am. Now I just need to catch up fixing the Unix warnings I'm seeing in those directories :). I've just committed SVN revision 21127 with these changes (to add -Werror under gcc only under the same directories /WX has been added in Windows by Ulf except his latest checkin-doing that now). I'll check for further warnings turned errors on my Mac since it has GCC v4 that may generate some additional warnings from my main dev box (FreBSD w/ GCC 3). Your patch breaks compilation when using the configure option --with-extra-gcc-checks Ciao Joerg -- Joerg Mayer [EMAIL PROTECTED] We are stuck with technology when what we really want is just stuff that works. Some say that should read Microsoft instead of technology. ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev
Re: [Wireshark-dev] Prevent compiler warnings by using stop on warnings/treat warnings as errors compiler option?
On Wed, Mar 21, 2007 at 05:46:50PM -0700, Stephen Fisher wrote: I've found a way around this issue and have introduced it into the same places in my tree on Unix as Ulf has on Windows so far. It's a variable setup by the configure script that is tested in each directory's Makefile.am. Now I just need to catch up fixing the Unix warnings I'm seeing in those directories :). I've just committed SVN revision 21127 with these changes (to add -Werror under gcc only under the same directories /WX has been added in Windows by Ulf except his latest checkin-doing that now). I'll check for further warnings turned errors on my Mac since it has GCC v4 that may generate some additional warnings from my main dev box (FreBSD w/ GCC 3). Steve ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev
Re: [Wireshark-dev] Prevent compiler warnings by using stop on warnings/treat warnings as errors compiler option?
On Tue, Mar 20, 2007 at 11:09:40PM -0700, Stephen Fisher wrote: Thanks. I introduced -Werror into the configure.in file in wiretap/ locally to follow Ulf's lead on the Win32 side and it broke the glib test program. The glib test program compiles with warnings (turned errors)! Something to look into... Glib and glib2 have some warnings that cannot be avoided, like declaring a function() instead of funktion(types). At least in one place there is even a comment that explains why this can't be fixed in the include. ciao Joerg -- Joerg Mayer [EMAIL PROTECTED] We are stuck with technology when what we really want is just stuff that works. Some say that should read Microsoft instead of technology. ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev
Re: [Wireshark-dev] Prevent compiler warnings by using stop on warnings/treat warnings as errors compiler option?
On Wed, Mar 21, 2007 at 08:29:45AM +0100, Joerg Mayer wrote: On Tue, Mar 20, 2007 at 11:09:40PM -0700, Stephen Fisher wrote: Thanks. I introduced -Werror into the configure.in file in wiretap/ locally to follow Ulf's lead on the Win32 side and it broke the glib test program. The glib test program compiles with warnings (turned errors)! Something to look into... Glib and glib2 have some warnings that cannot be avoided, like declaring a function() instead of funktion(types). At least in one place there is even a comment that explains why this can't be fixed in the include. But maybe you can configure your compiler to regard these includes as system includes, because (IIRC) by default gcc will suppress warnings from system includes. Ciao Joerg -- Joerg Mayer [EMAIL PROTECTED] We are stuck with technology when what we really want is just stuff that works. Some say that should read Microsoft instead of technology. ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev
Re: [Wireshark-dev] Prevent compiler warnings by using stop on warnings/treat warnings as errors compiler option?
Joerg Mayer wrote: No, it won't work. I've spent many many hours in the past to get rid of compiler warnings and it just won't work. While we definitely should try to get rid of some warnings, fixing warnings on one platform may introduce warnings on other platforms (or even gcc versions). Yes, I know there are very special cases where you'll have real problems getting a warning free code on all platforms / compilers / versions. One thing comes to my mind where this will be a problem: header files from our external libraries. BTW: Having a piece of code that doesn't compile without warnings on all platforms (unless you've triggered a real compiler bug) is often a good candidate for a code redesign - if the compiler doesn't like it most human developers will often also have problems to understand it ;-) But - these are really the exceptions and not the common thing. Most warnings can be fixed without problems. Some warnings will need special handling as there's no way to fix it (without making the code even uglier), it might be necessary to exclude code paths (#pragma) or even complete files from the general rule, as there's no realistic way to fix this in any other way. We might even need a configure option to disable the warning as error feature completely on platforms / compiler versions where this doesn't work. However, my goal would be to get a warning free build on the buildbot platforms, as that would be a big step into the right direction and that would make the situation much better even for the unsupported platforms ... Regards, ULFL ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev
Re: [Wireshark-dev] Prevent compiler warnings by using stop on warnings/treat warnings as errors compiler option?
Jeff Morriss wrote: In fact I meant it just as a stop-gap until someone (smarter--or at least with more than to dedicate to the purpose--than me) can fix Wireshark's unsigned-vs-signed char problem. As it is, I have to scroll through hundreds of (probably not fixable by me) warnings just to get to things I have a chance of fixing. There's so many that my eyes glaze over as I'm looking for warnings--which makes it hard to detect real (read: things I can do something about) warnings. When I've gone on warning-fixing kicks I've resorted to doing: % grep -i warn make.out | grep -iv signed | less to find the (real) warnings. :-( What you describe is one of the consequences with our current way of doing. Even people that are willing to fix their or other peoples warnings are having a hard time as there are so many of them :-( If you start to fix the warnings that you can fix, that'll be a lot better than doing nothing at all ;-) I just meant that in the long run just ignoring a long list of warnings is probably not a good idea ... However, disabling the signed warning, fix the rest and setting the stop on error barrier would still be a lot better than what we currently have ... Regards, ULFL ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev
Re: [Wireshark-dev] Prevent compiler warnings by using stop on warnings/treat warnings as errors compiler option?
Ulf Lamping wrote: I just meant that in the long run just ignoring a long list of warnings is probably not a good idea ... However, disabling the signed warning, fix the rest and setting the stop on error barrier would still be a lot better than what we currently have ... I heartily agree with Ulf on this - anything that you can do to reduce the number of warnings is a good thing. Currently, you don't tend to even notice new warnings that you introduce on your own platform, as they get lost in the general compilation noise. What needs to happen is a purge on as many warnings as possible, followed by turning on treat warnings as errors. This can be done platform-by-platform if need be. If you have to turn off the signed warning to make this viable, so be it - but it's there for a reason, and in general should be possible to fix properly rather than either just turning it off altogether, or casting away with a (void*). Incidentally, if anyone knows the right knob to stop gcc accepting variable declarations in the middle of a block of code, it really needs turning on. I manage to mess this up almost every time I submit a patch... ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev
Re: [Wireshark-dev] Prevent compiler warnings by using stop on warnings/treat warnings as errors compiler option?
Currently, you don't tend to even notice new warnings that you introduce on your own platform, as they get lost in the general compilation noise. Part of the problem (when working from the command-line at least) is how much output is generated, and how far you'd need to scroll back to see the compilation of the file you've just changed. For speed, I spend much of the time only compiling the one file, e.g. I'll run 'make epan/dissectors/packet-whatever.lo' until my changes compile. This makes my affect on the number of warnings pretty obvious. Incidentally, if anyone knows the right knob to stop gcc accepting variable declarations in the middle of a block of code, it really needs turning on. I manage to mess this up almost every time I submit a patch... _ I think -Wdeclaration-after-statement is what you need. Martin __ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev
Re: [Wireshark-dev] Prevent compiler warnings by using stop on warnings/treat warnings as errors compiler option?
Getting rid of warnings should not be confused with getting rid of the *reasons* for those warnings. -- Mark H. Wood, Lead System Programmer [EMAIL PROTECTED] Typically when a software vendor says that a product is intuitive he means the exact opposite. pgpomulJckxPF.pgp Description: PGP signature ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev
Re: [Wireshark-dev] Prevent compiler warnings by using stop on warnings/treat warnings as errors compiler option?
Inline comments... On 3/20/07, Martin Mathieson [EMAIL PROTECTED] wrote: Currently, you don't tend to even notice new warnings that you introduce on your own platform, as they get lost in the general compilation noise. Part of the problem (when working from the command-line at least) is how much output is generated, and how far you'd need to scroll back to see the compilation of the file you've just changed. For speed, I spend much of the time only compiling the one file, e.g. I'll run 'make epan/dissectors/packet-whatever.lo' until my changes compile. This makes my affect on the number of warnings pretty obvious. Which I believe is what we should all do. I been following a policy myself is that for every file I modify I remove all the warnings I get (well I leave there those for static functions not used and some about signedness of strings). If at least the committers take an approach of squelching warnings one file at a time, while we work on that file, little by little we can get rid of most (if not all) of them... I do not think we should deeply involve ourselves on a project of fixing warnings as a task on its own... I think our time is better used by either adding new features or fixing factual bugs, and while at it remove the warnings from the files we edit/patch. Incidentally, if anyone knows the right knob to stop gcc accepting variable declarations in the middle of a block of code, it really needs turning on. I manage to mess this up almost every time I submit a patch... I think -Wdeclaration-after-statement is what you need. I think that's what I need as well! -- This information is top security. When you have read it, destroy yourself. -- Marshall McLuhan ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev
Re: [Wireshark-dev] Prevent compiler warnings by using stop on warnings/treat warnings as errors compiler option?
On Tue, Mar 20, 2007 at 03:04:49AM +0100, Ulf Lamping wrote: In my experience having a compiler warning free code is a good way to prevent very subtle bugs and would also be a good addition to the programs security - and BTW more pleasant to work with ;-) Indeed. So here comes the buildbot into the scene. If we would use a compiler option like stop on warnings (or treat warnings as errors or alike), it would become at least much more obvious if new warnings were added - the buildbot will get red. This will also make the time when a warning is noticed much nearer to the time the code was added/changed - currently fixing a warning once added is often done much later than it was introduced (making the fix unnecessarily difficult). An incremental way to introduce this could be: Good ideas! As usual, this is my Win32 point of view. I'm pretty sure the above is possible to do for the Win32 platform. I'm not sure if it's possible with the automake foo for the different unix/linux platform builds ... With automake, we just need to put AM_CFLAGS = -Werror in the Makefile.am file in each directory that we're working on. So what's the opinion about this way to improve the Wireshark code base? Are we willing to produce only warning free code and fixing warnings that appear on the buildbot? Yes. While I would take a look on the Win32 warnings, are the unix/linux developers willing to spend some time to remove warnings that don't appear on Win32 (or would this be a Win32 only show)? I'm willing to work on the Unix warnings. Steve ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev
Re: [Wireshark-dev] Prevent compiler warnings by using stop on warnings/treat warnings as errors compiler option?
On Tue, Mar 20, 2007 at 01:01:20PM -0700, Stephen Fisher wrote: As usual, this is my Win32 point of view. I'm pretty sure the above is possible to do for the Win32 platform. I'm not sure if it's possible with the automake foo for the different unix/linux platform builds ... With automake, we just need to put AM_CFLAGS = -Werror in the Makefile.am file in each directory that we're working on. Of course, this assumes that all the C compilers we use accept -Werror. We may need to wrap this within compiler specific commands in the automake files. Steve ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev
Re: [Wireshark-dev] Prevent compiler warnings by using stop on warnings/treat warnings as errors compiler option?
On Tue, Mar 20, 2007 at 12:44:06PM +, Martin Mathieson wrote: Part of the problem (when working from the command-line at least) is how much output is generated, and how far you'd need to scroll back to see the compilation of the file you've just changed. Yup. I edit source files and compile in the Emacs GUI. It makes it easy to spot warnings errors during the compliation process (Control-X ` takes you to the next warning or error in the source code and in the compilation output). But you've got to have the right mindset to be able to stand using Emacs :). Steve ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev
Re: [Wireshark-dev] Prevent compiler warnings by using stop on warnings/treat warnings as errors compiler option?
On 3/21/07, Stephen Fisher [EMAIL PROTECTED] wrote: On Tue, Mar 20, 2007 at 12:44:06PM +, Martin Mathieson wrote: Yup. I edit source files and compile in the Emacs GUI. It makes it easy to spot warnings errors during the compliation process (Control-X ` takes you to the next warning or error in the source code and in the compilation output). But you've got to have the right mindset to be able to stand using Emacs :). How do you mean? Emacs is the only true editor! How would you edit sourcecode if not using emacs? ( http://www.dina.kvl.dk/~abraham/religion/ ) !6 :-) ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev
Re: [Wireshark-dev] Prevent compiler warnings by using stop on warnings/treat warnings as errors compiler option?
On Mar 20, 2007, at 5:21 PM, ronnie sahlberg wrote: How do you mean? Emacs is the only true editor! No, it's not: http://www.gnu.org/fun/jokes/ed.msg.html ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev
Re: [Wireshark-dev] Prevent compiler warnings by using stop on warnings/treat warnings as errors compiler option?
On Mar 20, 2007, at 1:08 PM, Stephen Fisher wrote: Of course, this assumes that all the C compilers we use accept - Werror. I doubt that they do (and they definitely don't, if by we you mean everybody who compiles Wireshark - it's been compiled with Sun C, HP's ANSI C compiler for HP-UX, and IBM's XLC compiler, among others). We may need to wrap this within compiler specific commands in the automake files. Or do it in the config file - look for -W in the top-level configure.in and the Wiretap configure.in. ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev
Re: [Wireshark-dev] Prevent compiler warnings by using stop on warnings/treat warnings as errors compiler option?
On 3/21/07, Guy Harris [EMAIL PROTECTED] wrote: On Mar 20, 2007, at 5:21 PM, ronnie sahlberg wrote: How do you mean? Emacs is the only true editor! No, it's not: http://www.gnu.org/fun/jokes/ed.msg.html There *must* be an ed mode for emacs. so the point is that... After some years using emacs I understood it was emacs to be using me. In fact, by then, most of my editing time was spent in info mode learning how to use things I would have never ever needed. -- This information is top security. When you have read it, destroy yourself. -- Marshall McLuhan ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev
Re: [Wireshark-dev] Prevent compiler warnings by using stop on warnings/treat warnings as errors compiler option?
Joerg Mayer wrote: No, it won't work. I've spent many many hours in the past to get rid of compiler warnings and it just won't work. While we definitely should try to get rid of some warnings, fixing warnings on one platform may introduce warnings on other platforms (or even gcc versions). In particular, as I remember, there's at least one warning where, at least as I read the ANSI C standard, MSVC++ 6.0 is confused and incorrectly reports a const vs. non-const warning - and, if you change the code to get rid of that warning, GCC, at least, then warns (correctly) about the type clash. ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev
Re: [Wireshark-dev] Prevent compiler warnings by using stop on warnings/treat warnings as errors compiler option?
On Mar 19, 2007, at 7:04 PM, Ulf Lamping wrote: In my experience having a compiler warning free code is a good way to prevent very subtle bugs and would also be a good addition to the programs security - and BTW more pleasant to work with ;-) You will often hear the following excuse on this topic: but you cannot write code which won't produce warnings on all those compilers out there. While there are cases where this is true (which has to be handled individually), it's much more often a sign of lazy / ignorant / unskilled developers IMHO. The main reason for warnings you can't eliminate, I suspect, are crufty vendor #include headers. At least some versions of Solaris have, as I remember, crappy old X11 headers that don't have function prototypes by default, hence the hack to turn them on in configure.in, and some don't declare a return type even with -DFUNCPROTO=15. If there are vendor headers that can't be worked around in a fashion such as that, some platforms might have a problem. If all else fails, we could leave the stop on warnings option off on that platform. Another issue is that a lot of code is automatically generated; I suspect both asn2wrs and the PIDL generator need to be fixed to decorate function arguments with _U_, or to leave the arguments out, or to generate code that uses them. For some reason, a lot of asn2wrs-generated files appear to generate a bunch of unused functions; I don't know if that's an asn2wrs problem or a problem with the ASN.1 being processed. In effect, the above is to introduce the new coding policy write warning free code and a way to enforce this. So what's the opinion about this way to improve the Wireshark code base? Are we willing to produce only warning free code and fixing warnings that appear on the buildbot? I think it's at least worth trying. ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev
Re: [Wireshark-dev] Prevent compiler warnings by using stop on warnings/treat warnings as errors compiler option?
Luis Ontanon wrote: the point is what kind of warnings can be cleaned up: Well, do you mean cannot be cleanup up or I'm too lazy to clean them up ;-) to fix pointer arguments differ in signedness for example would be a waste of time, as they are caused by guint8* used instaed of gchar* on those systems (most) that treat char as an unsigned. This is caused by random use of gchar/guint8 which is in effect not the same and BTW often done wrong. What you're completely missing here is the additional information provided using the right types to new developers who take a look at the code. I've often seen function declarations in the WS code that just uses the wrong types - in effect making a lot of dumb casts necessary. Simply ignoring this I know that this is the same is at least ignorant to other developers having a look at the code. But in order to follow that policy you'll have to fill the code with (void*) casts (which is ugly) beacuse if you simply work on a system that treats char as unsigned you can guess what would happen. Fixing something like gchar*/guint8* problems by using a (void*) cast, well, actually makes things worse. BTW a more tolerant policy of no *more* warnings (than those we already have) would be implementable by something like: cp warnings last_warnings make 21 warnings diff -u warnings last_warnings | grep '^+' || warn_and_blame_last_commiter While this might be a good start, having a no warning policy will work a lot better in the long run. Regards, ULFL ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev
Re: [Wireshark-dev] Prevent compiler warnings by using stop on warnings/treat warnings as errors compiler option?
I agree with Ulf. Warnings should not appear (at least most of them) when compiling wireshark. For the case differ in signedness case, you can use (guchar*). But as it was already discussed with Guy, wireshark needs a library to handle strings accurately. One starting point could simply be wrapping string functions and not use anymore gchar in wireshark but for example, uint8_t. Concerning, your second point, warn and blame last committer, I already thought that for helping the reviewers - which are a few for wireshark - there could have a simple script which could do some automated job when someone sends a patch to the list. For example : - if there are new warnings when compiling, etc - inspect use of deprecated C functions, deprecated wireshark functions, use of g_malloc, ... I already wrote a patch for flawfinder which inspects use of dangerous C functions taking into account only the set of changes induced by the patch. (available in the last version). We could extend it easily for wireshark purposes (like inspecting if the patch is using classic memory allocation functions or deprecated wireshark functions). Regards, Sebastien Tandel Luis Ontanon wrote: the point is what kind of warnings can be cleaned up: to fix pointer arguments differ in signedness for example would be a waste of time, as they are caused by guint8* used instaed of gchar* on those systems (most) that treat char as an unsigned. But in order to follow that policy you'll have to fill the code with (void*) casts (which is ugly) beacuse if you simply work on a system that treats char as unsigned you can guess what would happen. BTW a more tolerant policy of no *more* warnings (than those we already have) would be implementable by something like: cp warnings last_warnings make 21 warnings diff -u warnings last_warnings | grep '^+' || warn_and_blame_last_commiter On 3/20/07, Ulf Lamping [EMAIL PROTECTED] wrote: Hi List! In my experience having a compiler warning free code is a good way to prevent very subtle bugs and would also be a good addition to the programs security - and BTW more pleasant to work with ;-) You will often hear the following excuse on this topic: but you cannot write code which won't produce warnings on all those compilers out there. While there are cases where this is true (which has to be handled individually), it's much more often a sign of lazy / ignorant / unskilled developers IMHO. Unfortunately, we're currently having a clear trend to get more and more compiler warnings instead of less. Years ago, I've taken the work to remove warnings of the Win32 build to about 10, today we're having hundreds again :-( While I would be willing to remove code warnings for Win32, I first thought about how to prevent new warnings to rush in - otherwise any work on this topic would be annoying by seeing new warnings rushing in shortly. In my experience, preventing yourself to add new warnings to the WS is currently difficult because of the multi platform support. Even if you provide code that doesn't produce any warnings on your working platform, you won't simply notice any new warnings on other platforms (unless you take a look at the buildbot logs) - and compiling on multiple platforms all by yourself is not on option for most of the developers IMO. In the end this is what the buildbot is for. So here comes the buildbot into the scene. If we would use a compiler option like stop on warnings (or treat warnings as errors or alike), it would become at least much more obvious if new warnings were added - the buildbot will get red. This will also make the time when a warning is noticed much nearer to the time the code was added/changed - currently fixing a warning once added is often done much later than it was introduced (making the fix unnecessarily difficult). Simply add such a compiler option to the current code state (with it's hundreds of current warnings) would make the buildbot red on all platforms for a very long time - which is probably not a good idea. An incremental way to introduce this could be: a) cleanup the warnings for a specific submodule (e.g. wiretap) and platform (e.g. Win32) b) set the compiler option for this submodule only to get a barrier for new warnings to rush in c) continue with a) for next submodule :-) As usual, this is my Win32 point of view. I'm pretty sure the above is possible to do for the Win32 platform. I'm not sure if it's possible with the automake foo for the different unix/linux platform builds ... In effect, the above is to introduce the new coding policy write warning free code and a way to enforce this. So what's the opinion about this way to improve the Wireshark code base? Are we willing to produce only warning free code and fixing warnings that appear on the buildbot? While I would take a look on the Win32 warnings, are the unix/linux developers willing to spend some time to remove
Re: [Wireshark-dev] Prevent compiler warnings by using stop on warnings/treat warnings as errors compiler option?
Luis Ontanon wrote: the point is what kind of warnings can be cleaned up: to fix pointer arguments differ in signedness for example would be a waste of time, as they are caused by guint8* used instaed of gchar* on those systems (most) that treat char as an unsigned. Actually GCC already has a way to avoid this: -Wno-pointer-sign. Apparently: http://gcc.gnu.org/ml/gcc-patches/2005-01/msg00505.html someone didn't like the fact that Linux had a few thousand such warnings when compiled with GCC 4. We could add that and probably cut down the number of GCC warnings by, well, a few thousand. Unfortunately I can't quite seem to figure out how to (correctly) test if GCC will accept the option, though. Any ideas? ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev
Re: [Wireshark-dev] Prevent compiler warnings by using stop on warnings/treat warnings as errors compiler option?
Guy Harris wrote: The main reason for warnings you can't eliminate, I suspect, are crufty vendor #include headers. At least some versions of Solaris have, as I remember, crappy old X11 headers that don't have function prototypes by default, hence the hack to turn them on in configure.in, and some don't declare a return type even with -DFUNCPROTO=15. The same problem is with Windows headers and warning level 4 :-( You can do some #pragma warning magic for MSVC to get around this, but that's ugly. If there are vendor headers that can't be worked around in a fashion such as that, some platforms might have a problem. If all else fails, we could leave the stop on warnings option off on that platform. Ack. But I guess if we fix all warnings on the current buildbot platforms, this will reduce the current huge amount of warnings to a much better level even for the other platforms. Another issue is that a lot of code is automatically generated; I suspect both asn2wrs and the PIDL generator need to be fixed to decorate function arguments with _U_, or to leave the arguments out, or to generate code that uses them. For some reason, a lot of asn2wrs-generated files appear to generate a bunch of unused functions; I don't know if that's an asn2wrs problem or a problem with the ASN.1 being processed. Yes, that's one of the many steps to take. Unfortunately, I'm not very familiar with asn2wrs and the PIDL generator and will need some help on this ... I think it's at least worth trying. As you're one of the developers actually fixing warnings I thought that you would give it a try ;-) Regards, ULFL ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev
Re: [Wireshark-dev] Prevent compiler warnings by using stop on warnings/treat warnings as errors compiler option?
Jeff Morriss wrote: Actually GCC already has a way to avoid this: -Wno-pointer-sign. Apparently: http://gcc.gnu.org/ml/gcc-patches/2005-01/msg00505.html someone didn't like the fact that Linux had a few thousand such warnings when compiled with GCC 4. We could add that and probably cut down the number of GCC warnings by, well, a few thousand. Unfortunately I can't quite seem to figure out how to (correctly) test if GCC will accept the option, though. Any ideas? Well, you can disable almost any gcc warning, but that is not the point. It's about *fixing* warnings, not *ignoring* them :-) Regards, ULFL ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev
Re: [Wireshark-dev] Prevent compiler warnings by using stop on warnings/treat warnings as errors compiler option?
Ulf Lamping wrote: Jeff Morriss wrote: Actually GCC already has a way to avoid this: -Wno-pointer-sign. Apparently: http://gcc.gnu.org/ml/gcc-patches/2005-01/msg00505.html someone didn't like the fact that Linux had a few thousand such warnings when compiled with GCC 4. We could add that and probably cut down the number of GCC warnings by, well, a few thousand. Unfortunately I can't quite seem to figure out how to (correctly) test if GCC will accept the option, though. Any ideas? Well, you can disable almost any gcc warning, but that is not the point. It's about *fixing* warnings, not *ignoring* them :-) In fact I meant it just as a stop-gap until someone (smarter--or at least with more than to dedicate to the purpose--than me) can fix Wireshark's unsigned-vs-signed char problem. As it is, I have to scroll through hundreds of (probably not fixable by me) warnings just to get to things I have a chance of fixing. There's so many that my eyes glaze over as I'm looking for warnings--which makes it hard to detect real (read: things I can do something about) warnings. When I've gone on warning-fixing kicks I've resorted to doing: % grep -i warn make.out | grep -iv signed | less to find the (real) warnings. :-( ___ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev
