Re: [boost] Are warnings acceptable artifacts from builds?
"Static analysis means analyzing code at or before compile-time to check for correctness. Static analysis consists mostly of making sure SQLite compiles without warnings, even when all warnings are enabled. SQLite is developed primarily using GCC and it does compile without warnings on GCC using the -Wall and -Wextra flags. There are occasional reports of warnings coming from VC++, however. Static analysis has not proven to be helpful in finding bugs. We cannot call to mind a single problem in SQLite that was detected by static analysis that was not first seen by one of the other testing methods described above. On the other hand, we have on occasion introduced new bugs in our efforts to get SQLite to compile without warnings. Our experience, then, is that static analysis is counter-productive to quality. In other words, focusing on static analysis (being concerned with compiler warnings) actually reduces the quality of the code. Nevertheless, we developers have capitulated to pressure from users and actively work to eliminate compiler warnings. We are willing to do this because the other tests described above do an excellent job of finding the bugs that are often introduced when removing compiler warnings, so that product quality is probably not decreased as a result."
Vinnie wrote:
Static analysis has not proven to be helpful in finding bugs.
Considering that they use plain C, it is not very surprising that their "static analysis" by use of mild warning options has not proven to be helpful.
Our experience, then, [...]
Without even attempting a *real* static analysis, referring to "experience" is a bit misplaced. Just my very humble opinion. Back to topic: warnings should disappear at least from headers, *whenever possible*. Without real code separation between modules in C++, user applications are affected by library code. If a given user has a strict policy of not having *any* warnings during their build, then that policy is enough to prevent them from using Boost. I'm pretty sure that this scenario is not something that library authors would easily accept. Regards, -- Maciej Sobczak * www.msobczak.com * www.inspirel.com
Maciej Sobczak wrote:
Vinnie wrote:
Static analysis has not proven to be helpful in finding bugs.
Considering that they use plain C, it is not very surprising that their "static analysis" by use of mild warning options has not proven to be helpful.
Our experience, then, [...]
Without even attempting a *real* static analysis, referring to "experience" is a bit misplaced. Just my very humble opinion.
Back to topic: warnings should disappear at least from headers, *whenever possible*. Without real code separation between modules in C++, user applications are affected by library code. If a given user has a strict policy of not having *any* warnings during their build, then that policy is enough to prevent them from using Boost. I'm pretty sure that this scenario is not something that library authors would easily accept.
Well, we have that policy and still can use boost. We just find we're disabling warnings all over the place. Really silly stuff a lot of the time too, like someone comparing an int to a size_t. We simply had to disable the "assignment op could not be generated" warning. Unfortunately boost also causes an unreachable code warning and that we DON'T want to disable. There are many places that seem like they could use some cleaning up.
On Wed, Sep 9, 2009 at 9:50 AM, Noah Roberts <roberts.noah@gmail.com> wrote:
There are many places that seem like they could use some cleaning up.
Patches welcome. :-) Seriously, though, many programmers have only limited access to compilers other than their primary platform. I'm not a maintainer, but all the ones I've worked with have been gracious with patch proposals and grateful for someone taking the time to fix issues. *Runs off to take his own advice and put together that Wave V1 header warnings patch he's been meaning to do.* Christopher
Vinnie wrote:
"Static analysis means analyzing code at or before compile-time to check for correctness. Static analysis consists mostly of making sure SQLite compiles without warnings, even when all warnings are enabled. SQLite is developed primarily using GCC and it does compile without warnings on GCC using the -Wall and -Wextra flags. There are occasional reports of warnings coming from VC++, however.
Static analysis has not proven to be helpful in finding bugs. We cannot call to mind a single problem in SQLite that was detected by static analysis that was not first seen by one of the other testing methods described above. On the other hand, we have on occasion introduced new bugs in our efforts to get SQLite to compile without warnings.
Our experience, then, is that static analysis is counter-productive to quality. In other words, focusing on static analysis (being concerned with compiler warnings) actually reduces the quality of the code. Nevertheless, we developers have capitulated to pressure from users and actively work to eliminate compiler warnings. We are willing to do this because the other tests described above do an excellent job of finding the bugs that are often introduced when removing compiler warnings, so that product quality is probably not decreased as a result."
My experience has been quite the contrary. Chasing down compiler warnings has eliminated a good number of bugs in shared code here. Sure, some of the bugs could have been found with better testing, but we have what we have. Using a belt and suspenders is often helpful! Even for the SQLite team, eliminating all warnings makes new ones more promiment such that a developer is quickly alerted to what might be an issue before the code is checked in or undergoes testing. _____ Rob Stewart robert.stewart@sig.com Software Engineer, Core Software using std::disclaimer; Susquehanna International Group, LLP http://www.sig.com IMPORTANT: The information contained in this email and/or its attachments is confidential. If you are not the intended recipient, please notify the sender immediately by reply and immediately delete this message and all its attachments. Any review, use, reproduction, disclosure or dissemination of this message or any attachment by an unintended recipient is strictly prohibited. Neither this message nor any attachment is intended as or should be construed as an offer, solicitation or recommendation to buy or sell any security or other financial instrument. Neither the sender, his or her employer nor any of their respective affiliates makes any warranties as to the completeness or accuracy of any of the information contained herein or that this message or any of its attachments is free of viruses.
On Wed, Sep 9, 2009 at 11:22 AM, Stewart, Robert<Robert.Stewart@sig.com> wrote: > Vinnie wrote: >> >> >From http://sqlite.org/testing.html#coverage >> >> We cannot call to mind a single problem in SQLite that was >> detected by static analysis that was not first seen by one of >> the other testing methods described above. On the other hand, >> we have on occasion introduced new bugs in our efforts to get >> SQLite to compile without warnings. >> > > My experience has been quite the contrary. Chasing down compiler warnings has eliminated a good number of bugs in shared code here. Sure, some of the bugs could have been found with better testing, but we have what we have. Using a belt and suspenders is often helpful! > > Even for the SQLite team, eliminating all warnings makes new ones more promiment such that a developer is quickly alerted to what might be an issue before the code is checked in or undergoes testing. > We had a large code-base at Adobe that went through some warning removal nightmares. Definitely caused more bugs than it fixed. But once you get to 0, it makes new warnings easier to handle - and these new warnings will lead to bug fixes. Seems contradictory, but it is because new warnings are fixed with the code (and intentions) fresh in your mind; old warnings are fixed by guesses from non-original coders, who just want the warning to go away. >From my experience - be careful who fixes the warnings and how they do it - it is easy to screw up, particularly if it is code they are not completely familiar with. - having a large # of warning (1000's) makes it almost impossible to take the right amount of care to get that number down - you can quickly go from 0 to 1000 warnings by changing platforms/compilers/settings - some warnings really are useless, and more often than not should be ignored (with pragmas or globally) - once you get to 0, stay there :-) Tony
Gottlob Frege wrote: >> From my experience > - be careful who fixes the warnings and how they do it - it is easy > to > screw up, particularly if it is code they are not completely > familiar > with. > - having a large # of warning (1000's) makes it almost impossible to > take the right amount of care to get that number down > - you can quickly go from 0 to 1000 warnings by changing > platforms/compilers/settings > - some warnings really are useless, and more often than not should > be > ignored (with pragmas or globally) > - once you get to 0, stay there :-) I believe this last point is why some people so much dislike getting new warnings from library code. If you are at zero, you really, really want to stay there. Bo Persson
On Wed, Sep 09, 2009 at 05:54:13AM -0700, Vinnie wrote:
"Static analysis means analyzing code at or before compile-time to check for correctness. Static analysis consists mostly of making sure SQLite compiles without warnings, even when all warnings are enabled.
We cannot call to mind a single problem in SQLite that was detected by static analysis that was not first seen by one of the other testing methods described above.
It sounds like they're saying that no SQLite developer has ever made a change (even locally) that resulted in the code failing to compile. It sounds like they're saying the type-checker has never informed them of a bug in their code - I know C's type system is hardly worthy of the name, but still, these are pretty impressive claims. I don't think I can even claim to have worked on a project for a day without the compiler informing me of a problem in my code like the wrong number of *'s, assigning a value to a variable of the wrong type, forgetting the closing brace, or something similar; and I know I'm not a particularly error-prone programmer. -- "So long as we avoid accepting as true what is not so, and always preserve the right order of deduction of one thing from another, there can be nothing too remote to be reached in the end, or too well hidden to be discovered." -- Descartes, 269 years before Kurt Gödel was born
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Daniel Hulme skrev:
On Wed, Sep 09, 2009 at 05:54:13AM -0700, Vinnie wrote:
"Static analysis means analyzing code at or before compile-time to check for correctness. Static analysis consists mostly of making sure SQLite compiles without warnings, even when all warnings are enabled.
We cannot call to mind a single problem in SQLite that was detected by static analysis that was not first seen by one of the other testing methods described above.
It sounds like they're saying that no SQLite developer has ever made a change (even locally) that resulted in the code failing to compile. It sounds like they're saying the type-checker has never informed them of a bug in their code - I know C's type system is hardly worthy of the name, but still, these are pretty impressive claims. I don't think I can even claim to have worked on a project for a day without the compiler informing me of a problem in my code like the wrong number of *'s, assigning a value to a variable of the wrong type, forgetting the closing brace, or something similar; and I know I'm not a particularly error-prone programmer.
Actually, I believe they're claiming that they more heavily rely on a rather impressive unit- and regression testing scheme than on compiler warnings. No warning has ever informed them of a bug that their regression tests would not have caught. They then conclude that the compiler warnings may lead to lower quality code, which I have trouble believing. If rearranging or rewriting code to avoid a given compiler warning results in a bug then I suspect they have a design problem instead. YMMV. Just my chuck-in here. :-) /Brian -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.12 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkqqIRAACgkQk1tAOprY6QHlIACeMxqArA0DMeQn+S4LGjhM2eUj jo4AoK/m/fwb87AA9jW9wDHWkZbtKOS1 =GMgz -----END PGP SIGNATURE-----
On Fri, Sep 11, 2009 at 3:06 AM, Brian Ravnsgaard Riis <brian@ravnsgaard.net> wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Daniel Hulme skrev:
On Wed, Sep 09, 2009 at 05:54:13AM -0700, Vinnie wrote:
"Static analysis means analyzing code at or before compile-time to check for correctness. Static analysis consists mostly of making sure SQLite compiles without warnings, even when all warnings are enabled.
We cannot call to mind a single problem in SQLite that was detected by static analysis that was not first seen by one of the other testing methods described above.
It sounds like they're saying that no SQLite developer has ever made a change (even locally) that resulted in the code failing to compile. It sounds like they're saying the type-checker has never informed them of a bug in their code - I know C's type system is hardly worthy of the name, but still, these are pretty impressive claims. I don't think I can even claim to have worked on a project for a day without the compiler informing me of a problem in my code like the wrong number of *'s, assigning a value to a variable of the wrong type, forgetting the closing brace, or something similar; and I know I'm not a particularly error-prone programmer.
Actually, I believe they're claiming that they more heavily rely on a rather impressive unit- and regression testing scheme than on compiler warnings. No warning has ever informed them of a bug that their regression tests would not have caught.
If the "we want no warnings dammit" crowd main argument is "at my company we have zero-warnings policy, we can't do anything about it" then arguing whether or not any particular warning should be addressed is pointless (OTOH, I'd bet that no company has zero-warnings policy because some warnings can't be dealt with any other way but by disabling them.) Emil Dotchevski Reverge Studios, Inc. http://www.revergestudios.com/reblog/index.php?n=ReCode
Emil Dotchevski wrote:
If the "we want no warnings dammit" crowd main argument is "at my company we have zero-warnings policy, we can't do anything about it" then arguing whether or not any particular warning should be addressed is pointless (OTOH, I'd bet that no company has zero-warnings policy because some warnings can't be dealt with any other way but by disabling them.)
Disabling a warning, provided the scope is controlled, is fine. A company may craft a warnings policy, used whenever building code, that always disables select warnings, too, but that doesn't violate the zero warnings policy. Given a certain warnings configuration, however, developers at a zero warnings company expect builds to produce no warnings, which leads to expecting library cooperation. So long as the library author/maintainer is willing to try to eliminate warnings identified by users, there should be no problem. This is appropriate even for users that don't have a zero-warnings policy. _____ Rob Stewart robert.stewart@sig.com Software Engineer, Core Software using std::disclaimer; Susquehanna International Group, LLP http://www.sig.com IMPORTANT: The information contained in this email and/or its attachments is confidential. If you are not the intended recipient, please notify the sender immediately by reply and immediately delete this message and all its attachments. Any review, use, reproduction, disclosure or dissemination of this message or any attachment by an unintended recipient is strictly prohibited. Neither this message nor any attachment is intended as or should be construed as an offer, solicitation or recommendation to buy or sell any security or other financial instrument. Neither the sender, his or her employer nor any of their respective affiliates makes any warranties as to the completeness or accuracy of any of the information contained herein or that this message or any of its attachments is free of viruses.
On Fri, Sep 11, 2009 at 11:31 AM, Stewart, Robert <Robert.Stewart@sig.com> wrote:
Emil Dotchevski wrote:
If the "we want no warnings dammit" crowd main argument is "at my company we have zero-warnings policy, we can't do anything about it" then arguing whether or not any particular warning should be addressed is pointless (OTOH, I'd bet that no company has zero-warnings policy because some warnings can't be dealt with any other way but by disabling them.)
Disabling a warning, provided the scope is controlled, is fine.
Yes, but with GCC you can't control the scope.
A company may craft a warnings policy, used whenever building code, that always disables select warnings, too, but that doesn't violate the zero warnings policy.
My point exactly. This confirms that it is preferable, for that company, to disable some warnings instead of "fixing" them. This in turn leads to another interesting question: why don't they fix such warnings anyway? After all, that's what they're asking library developers to do for them, right? At least in some cases, I'm sure, the answer is "because that would do more harm than good" (as far as this particular company is concerned.) Therefore, if a library developer "fixes" a warning, some companies would consider that helpful, and some would consider it harmful (except, of course, companies that put their money where their mouth is, and never, ever disable any warnings.) Emil Dotchevski Reverge Studios, Inc. http://www.revergestudios.com/reblog/index.php?n=ReCode
Emil Dotchevski wrote:
On Fri, Sep 11, 2009 at 11:31 AM, Stewart, Robert <Robert.Stewart@sig.com> wrote:
Disabling a warning, provided the scope is controlled, is fine.
Yes, but with GCC you can't control the scope.
Right. That's a failing of GCC as far as I'm concerned.
A company may craft a warnings policy, used whenever building code, that always disables select warnings, too, but that doesn't violate the zero warnings policy.
My point exactly. This confirms that it is preferable, for that company, to disable some warnings instead of "fixing" them.
Disabling some warnings *is* the appropriate fix and I've never claimed otherwise.
This in turn leads to another interesting question: why don't they fix such warnings anyway? After all, that's what they're asking library developers to do for them, right? At least in some cases, I'm sure, the answer is "because that would do more harm than good" (as far as this particular company is concerned.)
If there is no good way to change the library code to prevent some particular warning from a compiler, then that should be documented and user's should be told that it can be silenced only by disabling that warning. I've never suggested the need to do more in that case. If there *is* a way to change the library code to prevent a warning, then it is reasonable to want the library author/maintainer to do so.
Therefore, if a library developer "fixes" a warning, some companies would consider that helpful, and some would consider it harmful
A change to the library code to silencing a warning would never be considered harmful unless it broke backward compatibility -- which Boost doesn't guarantee -- or it introduced a bug. The latter is a risk, of course, with any change, but should be vetted quickly enough. _____ Rob Stewart robert.stewart@sig.com Software Engineer, Core Software using std::disclaimer; Susquehanna International Group, LLP http://www.sig.com IMPORTANT: The information contained in this email and/or its attachments is confidential. If you are not the intended recipient, please notify the sender immediately by reply and immediately delete this message and all its attachments. Any review, use, reproduction, disclosure or dissemination of this message or any attachment by an unintended recipient is strictly prohibited. Neither this message nor any attachment is intended as or should be construed as an offer, solicitation or recommendation to buy or sell any security or other financial instrument. Neither the sender, his or her employer nor any of their respective affiliates makes any warranties as to the completeness or accuracy of any of the information contained herein or that this message or any of its attachments is free of viruses.
On Fri, Sep 11, 2009 at 12:06 PM, Stewart, Robert <Robert.Stewart@sig.com> wrote:
Emil Dotchevski wrote:
My point exactly. This confirms that it is preferable, for that company, to disable some warnings instead of "fixing" them.
Disabling some warnings *is* the appropriate fix and I've never claimed otherwise.
Sure, the question is who is to decide whether a particular warning should be disabled. I doubt that any library developer tolerates warnings in their code, except for the ones they've decided should be disabled. However, the case of matching opinions isn't interesting, this discussion is about how to handle situations when the library developer thinks a particular warning should be disabled (or not enabled) and someone else thinks otherwise.
This in turn leads to another interesting question: why don't they fix such warnings anyway? After all, that's what they're asking library developers to do for them, right? At least in some cases, I'm sure, the answer is "because that would do more harm than good" (as far as this particular company is concerned.)
If there is no good way to change the library code to prevent some particular warning from a compiler, then that should be documented and user's should be told that it can be silenced only by disabling that warning. I've never suggested the need to do more in that case.
We're back to square one with this argument. Obviously, if someone reports a warning and a library developer thinks there is a good way to fix the warning, it'll be fixed and that will be the end of it. The interesting case, again, is when there is no "good" way, for some definition of "good". It really is a problem of standardization. You don't see people arguing about whether a compile error should be fixed, such matter is resolved by fixes, workarounds and bug reports because there's agreed-upon authority (the ANSI standard) which is presumed correct. But warnings are issued in cases when the ANSI standard prohibits issuing an error, and this makes it difficult to craft a general policy that would be reasonable for everyone. Emil Dotchevski Reverge Studios, Inc. http://www.revergestudios.com/reblog/index.php?n=ReCode
Emil Dotchevski wrote:
Sure, the question is who is to decide whether a particular warning should be disabled. I doubt that any library developer tolerates warnings in their code, except for the ones they've decided should be
Unfortunately, many developers tolerate warnings.
disabled. However, the case of matching opinions isn't interesting, this discussion is about how to handle situations when the library developer thinks a particular warning should be disabled (or not enabled) and someone else thinks otherwise.
When did that become the discussion? I obviously missed the transition.
Obviously, if someone reports a warning and a library developer thinks there is a good way to fix the warning, it'll be fixed and that will be the end of it. The
This is a far cry from your earlier claim that someone complaining about a warning was being rude to you, the library developer. Nevertheless, I'm glad to see we've reached consensus.
interesting case, again, is when there is no "good" way, for some definition of "good".
Right.
It really is a problem of standardization. You don't see people arguing about whether a compile error should be fixed, such matter is resolved by fixes, workarounds and bug reports because there's agreed-upon authority (the ANSI standard) which is presumed correct. But warnings are issued in cases when the ANSI standard prohibits issuing an error, and this makes it difficult to craft a general policy that would be reasonable for everyone.
Exactly. Boost can determine a warning configuration for each supported compiler and can mandate the elimination of all warnings, with some possible exceptions that have no good solution. Whether agreement is possible to establish such a position is quite a leap from here, I'd guess. _____ Rob Stewart robert.stewart@sig.com Software Engineer, Core Software using std::disclaimer; Susquehanna International Group, LLP http://www.sig.com IMPORTANT: The information contained in this email and/or its attachments is confidential. If you are not the intended recipient, please notify the sender immediately by reply and immediately delete this message and all its attachments. Any review, use, reproduction, disclosure or dissemination of this message or any attachment by an unintended recipient is strictly prohibited. Neither this message nor any attachment is intended as or should be construed as an offer, solicitation or recommendation to buy or sell any security or other financial instrument. Neither the sender, his or her employer nor any of their respective affiliates makes any warranties as to the completeness or accuracy of any of the information contained herein or that this message or any of its attachments is free of viruses.
On Fri, Sep 11, 2009 at 1:35 PM, Stewart, Robert <Robert.Stewart@sig.com> wrote:
Emil Dotchevski wrote:
Obviously, if someone reports a warning and a library developer thinks there is a good way to fix the warning, it'll be fixed and that will be the end of it. The
This is a far cry from your earlier claim that someone complaining about a warning was being rude to you, the library developer. Nevertheless, I'm glad to see we've reached consensus.
Complaining is fine, it's a free country. :) What I meant is that often, when reporting a warning, people presume that it would be unreasonable not to fix the warning, which I think is inappropriate in the sense that they don't recognize that their ask may be entirely based on a personal preference others might find unreasonable. Perhaps "rude" isn't the right word to describe this, yes. Emil Dotchevski Reverge Studios, Inc. http://www.revergestudios.com/reblog/index.php?n=ReCode
AMDG Emil Dotchevski wrote:
On Fri, Sep 11, 2009 at 11:31 AM, Stewart, Robert <Robert.Stewart@sig.com> wrote:
Emil Dotchevski wrote:
If the "we want no warnings dammit" crowd main argument is "at my company we have zero-warnings policy, we can't do anything about it" then arguing whether or not any particular warning should be addressed is pointless (OTOH, I'd bet that no company has zero-warnings policy because some warnings can't be dealt with any other way but by disabling them.)
Disabling a warning, provided the scope is controlled, is fine.
Yes, but with GCC you can't control the scope.
It isn't quite as fine-grained as msvc's mechanism, but you can use #pragma GCC system_header It seems to handle templates okay in recent versions. In Christ, Steven Watanabe
On Fri, Sep 11, 2009 at 4:04 PM, Steven Watanabe <watanabesj@gmail.com> wrote:
AMDG Emil Dotchevski wrote:
On Fri, Sep 11, 2009 at 11:31 AM, Stewart, Robert <Robert.Stewart@sig.com> wrote:
Emil Dotchevski wrote:
If the "we want no warnings dammit" crowd main argument is "at my company we have zero-warnings policy, we can't do anything about it" then arguing whether or not any particular warning should be addressed is pointless (OTOH, I'd bet that no company has zero-warnings policy because some warnings can't be dealt with any other way but by disabling them.)
Disabling a warning, provided the scope is controlled, is fine.
Yes, but with GCC you can't control the scope.
It isn't quite as fine-grained as msvc's mechanism, but you can use #pragma GCC system_header It seems to handle templates okay in recent versions.
I was wondering if the GCC pragma works well. If it really does, why not just add it in boost/config and be done with it. :) Emil Dotchevski Reverge Studios, Inc. http://www.revergestudios.com/reblog/index.php?n=ReCode
AMDG Emil Dotchevski wrote:
On Fri, Sep 11, 2009 at 4:04 PM, Steven Watanabe <watanabesj@gmail.com> wrote:
It isn't quite as fine-grained as msvc's mechanism, but you can use #pragma GCC system_header It seems to handle templates okay in recent versions.
I was wondering if the GCC pragma works well. If it really does, why not just add it in boost/config and be done with it. :)
As I understand it, the pragma operates only on the header it's in, so I don't see how it can easily be factored out. In Christ, Steven Watanabe
On Fri, Sep 11, 2009 at 4:22 PM, Steven Watanabe <watanabesj@gmail.com> wrote:
AMDG
Emil Dotchevski wrote:
On Fri, Sep 11, 2009 at 4:04 PM, Steven Watanabe <watanabesj@gmail.com> wrote:
It isn't quite as fine-grained as msvc's mechanism, but you can use #pragma GCC system_header It seems to handle templates okay in recent versions.
I was wondering if the GCC pragma works well. If it really does, why not just add it in boost/config and be done with it. :)
As I understand it, the pragma operates only on the header it's in, so I don't see how it can easily be factored out.
Oh right, what a lame suggestion I made :) Well umm I'm not sure it's helpful at all then. It would be nice to be able to pass to the compiler a list of paths it should consider "3rd-party" and not warn unless the warning depends on user constructs, which I guess fits your statement that it handles templates okay. But maybe that's problematic for the same reasons pragma once is. Emil Dotchevski Reverge Studios, Inc. http://www.revergestudios.com/reblog/index.php?n=ReCode
AMDG Emil Dotchevski wrote:
Well umm I'm not sure it's helpful at all then. It would be nice to be able to pass to the compiler a list of paths it should consider "3rd-party" and not warn unless the warning depends on user constructs, which I guess fits your statement that it handles templates okay. But maybe that's problematic for the same reasons pragma once is.
You can use -isystem instead of -I. In Christ, Steven Watanabe
On Fri, Sep 11, 2009 at 4:40 PM, Steven Watanabe <watanabesj@gmail.com> wrote:
AMDG
Emil Dotchevski wrote:
Well umm I'm not sure it's helpful at all then. It would be nice to be able to pass to the compiler a list of paths it should consider "3rd-party" and not warn unless the warning depends on user constructs, which I guess fits your statement that it handles templates okay. But maybe that's problematic for the same reasons pragma once is.
You can use -isystem instead of -I.
Could someone test this with Boost, that is, could someone confirm that using this approach gets rid of (only) the unwanted warnings? Emil Dotchevski Reverge Studios, Inc. http://www.revergestudios.com/reblog/index.php?n=ReCode
Il giorno 12/set/2009, alle ore 01.46, Emil Dotchevski <emildotchevski@gmail.com
ha scritto:
On Fri, Sep 11, 2009 at 4:40 PM, Steven Watanabe <watanabesj@gmail.com> wrote:
AMDG
Emil Dotchevski wrote:
Well umm I'm not sure it's helpful at all then. It would be nice to be able to pass to the compiler a list of paths it should consider "3rd-party" and not warn unless the warning depends on user constructs, which I guess fits your statement that it handles templates okay. But maybe that's problematic for the same reasons pragma once is.
You can use -isystem instead of -I.
Could someone test this with Boost, that is, could someone confirm that using this approach gets rid of (only) the unwanted warnings?
Fwiw, I usually never see warnings from boost code because it comes installed from my os, a Linux distro, in /usr/include which gcc implicitly treats as -isystem. -- Gpd Inviato da iPhone
Gpderetta wrote:
Il giorno 12/set/2009, alle ore 01.46, Emil Dotchevski <emildotchevski@gmail.com> ha scritto:
On Fri, Sep 11, 2009 at 4:40 PM, Steven Watanabe <watanabesj@gmail.com> wrote:
AMDG
You can use -isystem instead of -I.
Could someone test this with Boost, that is, could someone confirm that using this approach gets rid of (only) the unwanted warnings?
Fwiw, I usually never see warnings from boost code because it comes installed from my os, a Linux distro, in /usr/include which gcc implicitly treats as -isystem.
This is not the case for other unix systems. E.g. freebsd has user headers in /usr/local/include and gcc doesn't treat this path as system. BR, Dmitry
Emil Dotchevski wrote:
On Fri, Sep 11, 2009 at 4:40 PM, Steven Watanabe <watanabesj@gmail.com> wrote:
AMDG
Emil Dotchevski wrote:
Well umm I'm not sure it's helpful at all then. It would be nice to be able to pass to the compiler a list of paths it should consider "3rd-party" and not warn unless the warning depends on user constructs, which I guess fits your statement that it handles templates okay. But maybe that's problematic for the same reasons pragma once is.
You can use -isystem instead of -I.
Could someone test this with Boost, that is, could someone confirm that using this approach gets rid of (only) the unwanted warnings?
Looks like I've made too subtle reference to -isystem in a prior post, where I've said: For bonus points, assume that Boost is not installed system-wide, but is included in the project, possibly with local tweaks. Using -isystem is fine if, and only if the application developer believe that the Boost libraries that he is using were tested on exactly the same compiler and operating system, and the version tested was exactly the same, and the warnings were examined by the library developer and were found to be bogus. Now, if I'm a building Boost as part of build process for my project, and my version of gcc is not in the regular regression matrix, or I use trunk snapshot with local modifications, then -isystem becomes rather questionable. Not to mention that I don't remember ever seeing "known warnings" table for any Boost library. - Volodya
For the sake of argument, suppose I wanted to attempt to reduce or eliminate warnings for the library I maintain. How would I go about doing this? I can see the warnings when I build the library on my own machine. But I can't see any warnings when I view the test results matrix. Even if it produces warnings, it shows green with no link to view the bjam output. Perhaps if the warnings were accessible, there might be more motivation to address them. Robert Ramey
Robert Ramey wrote:
For the sake of argument, suppose I wanted to attempt to reduce or eliminate warnings for the library I maintain. How would I go about doing this? I can see the warnings when I build the library on my own machine. But I can't see any warnings when I view the test results matrix. Even if it produces warnings, it shows green with no link to view the bjam output. Perhaps if the warnings were accessible, there might be more motivation to address them.
This is true. Though reverse argument may also be true -- no library developer ever asked for warnings to be shown. If this is desirable, I'm sure warnings can be hacked in. - Volodya
Vladimir Prus wrote:
Robert Ramey wrote:
For the sake of argument, suppose I wanted to attempt to reduce or eliminate warnings for the library I maintain. How would I go about doing this? I can see the warnings when I build the library on my own machine. But I can't see any warnings when I view the test results matrix. Even if it produces warnings, it shows green with no link to view the bjam output. Perhaps if the warnings were accessible, there might be more motivation to address them.
This is true. Though reverse argument may also be true -- no library developer ever asked for warnings to be shown.
OK - I'm asking.
If this is desirable, I'm sure warnings can be hacked in.
- Volodya
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Robert Ramey wrote:
Vladimir Prus wrote:
Robert Ramey wrote:
For the sake of argument, suppose I wanted to attempt to reduce or eliminate warnings for the library I maintain. How would I go about doing this? I can see the warnings when I build the library on my own machine. But I can't see any warnings when I view the test results matrix. Even if it produces warnings, it shows green with no link to view the bjam output. Perhaps if the warnings were accessible, there might be more motivation to address them.
This is true. Though reverse argument may also be true -- no library developer ever asked for warnings to be shown.
OK - I'm asking.
I went back and checked the results table on my local machine. This table is generated by invoking ../../../tools/regression/src/library_test.sh (or bat) from BOOST_ROOT/libs/serialization/test directory. It shows links for warning output when when the test passes with a warning. I never really looked at these before. Now that I do it seems almost all are due to one particular header that has an easy fix. A couple of others - e.g. using hash rather than unordered emit warnings which are legitimate so I won't mess with them. Seems that I'm almost off the hook here. Robert Ramey
On Sat, Sep 12, 2009 at 6:50 AM, Vladimir Prus <vladimir@codesourcery.com> wrote:
Emil Dotchevski wrote:
On Fri, Sep 11, 2009 at 4:40 PM, Steven Watanabe <watanabesj@gmail.com> wrote:
AMDG
Emil Dotchevski wrote:
Well umm I'm not sure it's helpful at all then. It would be nice to be able to pass to the compiler a list of paths it should consider "3rd-party" and not warn unless the warning depends on user constructs, which I guess fits your statement that it handles templates okay. But maybe that's problematic for the same reasons pragma once is.
You can use -isystem instead of -I.
Could someone test this with Boost, that is, could someone confirm that using this approach gets rid of (only) the unwanted warnings?
Using -isystem is fine if, and only if the application developer believe that the Boost libraries that he is using were tested on exactly the same compiler and operating system, and the version tested was exactly the same, and the warnings were examined by the library developer and were found to be bogus.
You're thinking of warnings too narrowly. It seems like in your mind a warning indicates a possible problem, the developer examines the code, and by "fixing" the warning confirms that it's all good. With this mindset, you've already assumed that the warning in question could possibly indicate a problem, which isn't true for all warnings. I'm not saying that this approach doesn't apply most of the time. I'm with Robert: I'll look at warnings generated by tests on various platforms if the testing framework highlights them, and more often than not I'll fix the warning with appreciation. But when warnings attempt to enforce design or question design decisions, I think that it is not unreasonable for a library developer to disagree. All things considered, in my opinion, -isystem is a good idea.
Now, if I'm a building Boost as part of build process for my project, and my version of gcc is not in the regular regression matrix, or I use trunk snapshot with local modifications, then -isystem becomes rather questionable.
Sure, but in this case you're taking a significant risk already. Ask me how I know. :) Emil Dotchevski Reverge Studios, Inc. http://www.revergestudios.com/reblog/index.php?n=ReCode
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Emil Dotchevski skrev:
On Fri, Sep 11, 2009 at 3:06 AM, Brian Ravnsgaard Riis <brian@ravnsgaard.net> wrote:
Actually, I believe they're claiming that they more heavily rely on a rather impressive unit- and regression testing scheme than on compiler warnings. No warning has ever informed them of a bug that their regression tests would not have caught.
If the "we want no warnings dammit" crowd main argument is "at my company we have zero-warnings policy, we can't do anything about it" then arguing whether or not any particular warning should be addressed is pointless (OTOH, I'd bet that no company has zero-warnings policy because some warnings can't be dealt with any other way but by disabling them.)
Uhm.. Which wasn't actually what I was trying to address. My comment was solely pointed at the SQLite-crowd comment, that they believe warnings are not just meaningless, but dangerous. My position (should you want it) is that warnings should not be ignored *out of hand*, and if you do ignore it, you should try to shut the compiler up. Having loads of warnings scroll by that you "know" do no real harm lowers your attention to warnings in general, so you're less likely to notice when something serious shows up, which it *will* sooner or later. I'm not saying that the boost libraries should be warning-free at all warning levels on all compilers; this is nigh impossible in the real world. I *do* believe that, as Volodya mentioned, compiling error-free on a select set of compilers at a given (read: reasonable) warning level should be possible. Obviously G++ and MSVC are what I'm thinking about here, but both this and the given warning level should be stated somewhere in connection with the coding standards. /Brian -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.12 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkqqn1kACgkQk1tAOprY6QGZiACfXiQcbOS41qOmNB/hBKOBzu9R /hYAn32SaTpH6j0NBR/5arlomTLOIzSe =24T8 -----END PGP SIGNATURE-----
On 09/09/09 8:54 AM, Vinnie wrote:
"Static analysis means analyzing code at or before compile-time to check for correctness. Static analysis consists mostly of making sure SQLite compiles without warnings, even when all warnings are enabled. SQLite is developed primarily using GCC and it does compile without warnings on GCC using the -Wall and -Wextra flags. There are occasional reports of warnings coming from VC++, however.
Static analysis has not proven to be helpful in finding bugs. We cannot call to mind a single problem in SQLite that was detected by static analysis that was not first seen by one of the other testing methods described above. On the other hand, we have on occasion introduced new bugs in our efforts to get SQLite to compile without warnings.
Our experience, then, is that static analysis is counter-productive to quality. In other words, focusing on static analysis (being concerned with compiler warnings) actually reduces the quality of the code. Nevertheless, we developers have capitulated to pressure from users and actively work to eliminate compiler warnings. We are willing to do this because the other tests described above do an excellent job of finding the bugs that are often introduced when removing compiler warnings, so that product quality is probably not decreased as a result."
The SQLite developers are pretty good so I'm not saying that they are wrong. But... Just because they had problems doing something does not mean it should not be done. I enable warnings as errors in all my projects but for cross-platform code, it is really difficult to get right especially when a compiler/platform is added much later. Most of the time it ends up being stuff like "loss of data due to conversion" if we assign a size_t to an int so it helps to look at the line of code and make sure that it is safe. After all, every bug found later costs more money. -- Sohail Somani http://uint32t.blogspot.com
participants (16)
-
Bo Persson -
Brian Ravnsgaard Riis -
Christopher Currie -
Daniel Hulme -
Dmitry Goncharov -
Emil Dotchevski -
Gottlob Frege -
Gpderetta -
Maciej Sobczak -
Noah Roberts -
Robert Ramey -
Sohail Somani -
Steven Watanabe -
Stewart, Robert -
Vinnie -
Vladimir Prus