Current Guidance on Compiler Warnings?

classic Classic list List threaded Threaded
104 messages Options
1234 ... 6
Reply | Threaded
Open this post in threaded view
|

Current Guidance on Compiler Warnings?

Boost - Dev mailing list
I'd like to confirm the guidance on Warnings I find here
https://svn.boost.org/trac10/wiki/Guidelines/WarningsGuidelines
is still considered current?

context ...

At Wind River we are in the process of working with Boost 1.68 and VxWorks
7 (with Dinkum 7.00  with and Clang  6.0 for ARM and IA boards and  GCC 8.1
for PowerPC ) with the hope of bundling Boost with our product.

Many of our customers make certified systems ( Planes, Trains, Medical
Equipment, Factory Automation, etc. ) and the trend in theses industries is
to be pedantic about eliminating all compiler warnings.

While we have not traditionally required zero warnings in open source code
shipped with our product, there is pressure on us to move in that
direction, and as result we will probably be contributing pull requests
specifically to fix or suppress compiler warnings over the coming years.

I'd like to establish clear guidelines for my team as to what is an
appropriate "coding standard" for Boost in regards to compiler warnings.
While it is simple to say, everything displayed by -Wall, in practice there
are many edge cases,  e.g. is an unused parameter acceptable in test code?
So I'd like to get the maintainers guidance.

Many thanks

Brian Kuhl

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: Current Guidance on Compiler Warnings?

Boost - Dev mailing list

On 19/11/2018 19:20, Brian Kuhl via Boost wrote:
> I'd like to confirm the guidance on Warnings I find here
> https://svn.boost.org/trac10/wiki/Guidelines/WarningsGuidelines
> is still considered current?


More or less - the advice could use updating, and each new compiler
release brings new warnings, some busy-body some not, so it's a constant
struggle to catch up.

Speaking for myself I'm happy to fix or suppress (as appropriate)
warnings in my stuff, so bring on the PR's I would say ;)

Of course you may have to nag the community maintenance team if you're
submitting PR's against unmaintained libraries.

HTH, John.

>
> context ...
>
> At Wind River we are in the process of working with Boost 1.68 and VxWorks
> 7 (with Dinkum 7.00  with and Clang  6.0 for ARM and IA boards and  GCC 8.1
> for PowerPC ) with the hope of bundling Boost with our product.
>
> Many of our customers make certified systems ( Planes, Trains, Medical
> Equipment, Factory Automation, etc. ) and the trend in theses industries is
> to be pedantic about eliminating all compiler warnings.
>
> While we have not traditionally required zero warnings in open source code
> shipped with our product, there is pressure on us to move in that
> direction, and as result we will probably be contributing pull requests
> specifically to fix or suppress compiler warnings over the coming years.
>
> I'd like to establish clear guidelines for my team as to what is an
> appropriate "coding standard" for Boost in regards to compiler warnings.
> While it is simple to say, everything displayed by -Wall, in practice there
> are many edge cases,  e.g. is an unused parameter acceptable in test code?
> So I'd like to get the maintainers guidance.
>
> Many thanks
>
> Brian Kuhl
>
> _______________________________________________
> Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
>

---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus


_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: Current Guidance on Compiler Warnings?

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
On Mon, Nov 19, 2018 at 11:21 AM Brian Kuhl via Boost <[hidden email]>
wrote:
>
> I'd like to confirm the guidance on Warnings I find here
> https://svn.boost.org/trac10/wiki/Guidelines/WarningsGuidelines
> is still considered current?
>
> context ...
>
> At Wind River we are in the process of working with Boost 1.68 and VxWorks
> 7 (with Dinkum 7.00  with and Clang  6.0 for ARM and IA boards and  GCC
8.1
> for PowerPC ) with the hope of bundling Boost with our product.
>
> Many of our customers make certified systems ( Planes, Trains, Medical
> Equipment, Factory Automation, etc. ) and the trend in theses industries
is
> to be pedantic about eliminating all compiler warnings.

In that context there are probably legal reason for zero-warning policy,
but it is not true that lack of warnings means fewer errors, in fact it
could easily lead to more errors. For example warnings about implicit
conversions are frequently "fixed" by replacing the implicit conversion
with explicit conversion (cast). But the two are semantically very
different, and therefore one of them is incorrect, and very likely that is
the explicit one.

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: Current Guidance on Compiler Warnings?

Boost - Dev mailing list
On Monday, 19 November 2018 21:02:55 CET Emil Dotchevski via Boost wrote:
> In that context there are probably legal reason for zero-warning policy,
> but it is not true that lack of warnings means fewer errors, in fact it
> could easily lead to more errors. For example warnings about implicit
> conversions are frequently "fixed" by replacing the implicit conversion
> with explicit conversion (cast). But the two are semantically very
> different, and therefore one of them is incorrect, and very likely that is
> the explicit one.

Didn't know that. Can I see an example where the explicit warning is  
incorrect as opposed to implicit warning?

Thanks

--
Cheers
Jayesh Badwaik
https://jayeshbadwaik.github.io

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Current Guidance on Compiler Warnings?

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
On Mon, Nov 19, 2018 at 2:44 PM John Maddock via Boost <
[hidden email]> wrote:

>
> On 19/11/2018 19:20, Brian Kuhl via Boost wrote:
> > I'd like to confirm the guidance on Warnings I find here
> > https://svn.boost.org/trac10/wiki/Guidelines/WarningsGuidelines
> > is still considered current?
>
>
> More or less - the advice could use updating, and each new compiler
> release brings new warnings, some busy-body some not, so it's a constant
> struggle to catch up.
>
> Speaking for myself I'm happy to fix or suppress (as appropriate)
> warnings in my stuff, so bring on the PR's I would say ;)
>
> Of course you may have to nag the community maintenance team if you're
> submitting PR's against unmaintained libraries.
>
> HTH, John.
>
>
Nagging will not be required; I prefer warning-free builds as well.
None of the CMT repositories use "warnings-as-errors" as a build setting
however,
so the CI builds will not test or guarantee no warnings.  Would love to get
there.
A list of CMT repositories can be found here:
https://svn.boost.org/trac10/wiki/CommunityMaintenance

- Jim

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: Current Guidance on Compiler Warnings?

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
On Mon, 19 Nov 2018, Brian Kuhl via Boost wrote:

> I'd like to confirm the guidance on Warnings I find here
> https://svn.boost.org/trac10/wiki/Guidelines/WarningsGuidelines
> is still considered current?
>
> context ...
>
> At Wind River we are in the process of working with Boost 1.68 and VxWorks
> 7 (with Dinkum 7.00  with and Clang  6.0 for ARM and IA boards and  GCC 8.1
> for PowerPC ) with the hope of bundling Boost with our product.

If you are bundling Boost with your product, can't you mandate the use of
-isystem to include it, and thus disable most boost warnings at once?

--
Marc Glisse

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: Current Guidance on Compiler Warnings?

Boost - Dev mailing list
On Mon, Nov 19, 2018 at 12:34 PM Marc Glisse via Boost <
[hidden email]> wrote:

> On Mon, 19 Nov 2018, Brian Kuhl via Boost wrote:
>
> > I'd like to confirm the guidance on Warnings I find here
> > https://svn.boost.org/trac10/wiki/Guidelines/WarningsGuidelines
> > is still considered current?
> >
> > context ...
> >
> > At Wind River we are in the process of working with Boost 1.68 and
> VxWorks
> > 7 (with Dinkum 7.00  with and Clang  6.0 for ARM and IA boards and  GCC
> 8.1
> > for PowerPC ) with the hope of bundling Boost with our product.
>
> If you are bundling Boost with your product, can't you mandate the use of
> -isystem to include it, and thus disable most boost warnings at once?
>

+1.

And there is also #pragma system_header, which I use in my Boost libraries,
but people who think that being pedantic about warnings is a good idea
don't like that at all.

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: Current Guidance on Compiler Warnings?

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
On 11/19/2018 2:20 PM, Brian Kuhl via Boost wrote:

> I'd like to confirm the guidance on Warnings I find here
> https://svn.boost.org/trac10/wiki/Guidelines/WarningsGuidelines
> is still considered current?
>
> context ...
>
> At Wind River we are in the process of working with Boost 1.68 and VxWorks
> 7 (with Dinkum 7.00  with and Clang  6.0 for ARM and IA boards and  GCC 8.1
> for PowerPC ) with the hope of bundling Boost with our product.
>
> Many of our customers make certified systems ( Planes, Trains, Medical
> Equipment, Factory Automation, etc. ) and the trend in theses industries is
> to be pedantic about eliminating all compiler warnings.
>
> While we have not traditionally required zero warnings in open source code
> shipped with our product, there is pressure on us to move in that
> direction, and as result we will probably be contributing pull requests
> specifically to fix or suppress compiler warnings over the coming years.
>
> I'd like to establish clear guidelines for my team as to what is an
> appropriate "coding standard" for Boost in regards to compiler warnings.
> While it is simple to say, everything displayed by -Wall, in practice there
> are many edge cases,  e.g. is an unused parameter acceptable in test code?
> So I'd like to get the maintainers guidance.

Warning free is a nice ideal, but the truth is more complicated. Many
warnings are not really about possible coding mishaps but about a sort
of lint-like standard which compilers now want to enforce and have
nothing to do with correct C++ code. Other warnings are simply
erroneous, as is prevalent most everywhere in the current default VC++
preprocessor. Eliminate even the first class of warnings is often a
fool's errand AFAIAC. All one ends up doing is adding completely
unnecessary code restrictions to what is perfectly acceptable C++ code.
A typical example is some variable whose name hides a variable in an
outer scope. This is perfectly acceptable C++ code but now many
compilers issue a warning when this happens. I object to having to worry
about coming up with a unique name to all variables in whatever scope in
some translation unit just to avoid such a warning. This process of
warnings enforcing coding standards goes on and on and I do not think it
is possible, or advisable timewise, to spend unnecessary time pleasing
every compiler's notion of what these lint-like warnings entail. I am
not against spending time eliminating warnings when the warning itself
points top some loose use of C++. But I am against spending time on
eliminating warnings when the warning is just some lint-like alarm over
what might be an error but is perfectly normal and acceptable C++ code.

>
> Many thanks
>
> Brian Kuhl


_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: Current Guidance on Compiler Warnings?

Boost - Dev mailing list
On Mon, Nov 19, 2018 at 1:02 PM Edward Diener via Boost <
[hidden email]> wrote:
> I do not think it
> is possible, or advisable timewise, to spend unnecessary time pleasing
> every compiler's notion of what these lint-like warnings entail.

+1

This can be done for an enumerated list of compiler versions and platforms,
but it can NOT be done in general. Another compiler (or the next version of
the same compiler) will introduce new warnings. The idea that warnings
always indicate potential problems is fundamentally flawed.

It follows that always running the compiler at the maximum warning setting
is fundamentally flawed, too. Its legitimate use is not as a shield against
bugs, but as a debugging tool: if you suspect that a source file contains a
subtle bug, you could compile it with maximum linting, examine every
warning closely, then turn it back off.

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: Current Guidance on Compiler Warnings?

Boost - Dev mailing list
On Tue, 20 Nov 2018 at 01:31, Emil Dotchevski via Boost <
[hidden email]> wrote:

> if you suspect that a source file contains a
> subtle bug, you could compile it with maximum linting, examine every
> warning closely, then turn it back off.
>

+1

Or simply just once in a while (during dev) and walk through all those
warnings just to verify nothing is actually wrong, it least it [the
compiler] tells you where to have a look. It's now much better, but there
was a time that running the highest warning level with the VC-STL would
turn up mostly warnings in the STL.

I also used the ICC for a long time [in the past], high warning levels was
simply impossible [with the VC-STL], which gave the impression the whole
VC-STL needed a re-write [which it probably did ;-) ].

degski
--
*“If something cannot go on forever, it will stop" - Herbert Stein*

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: Current Guidance on Compiler Warnings?

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
On Mon, Nov 19, 2018 at 1:20 PM Brian Kuhl via Boost <[hidden email]>
wrote:

> I'd like to confirm the guidance on Warnings I find here
> https://svn.boost.org/trac10/wiki/Guidelines/WarningsGuidelines
> is still considered current?
>
> context ...
>
> At Wind River we are in the process of working with Boost 1.68 and VxWorks
> 7 (with Dinkum 7.00  with and Clang  6.0 for ARM and IA boards and  GCC 8.1
> for PowerPC ) with the hope of bundling Boost with our product.
>
> Many of our customers make certified systems ( Planes, Trains, Medical
> Equipment, Factory Automation, etc. ) and the trend in theses industries is
> to be pedantic about eliminating all compiler warnings.
>

As someone who works with VxWorks at a company that does one of the above
(Planes), I'm happy to see Wind River finally getting to this point!

One thing that I think the community would find useful, would be if Wind
River would stand up some VxWorks-based tests environments that can run our
suite of regression tests. This would allow developers to get rapid
feedback on the affect of their changes to boost on VxWorks, including if
they introduce warnings. It would also be nice/useful to get the Dinkum
libraries tested separately from the VxWorks platform.

There are instructions for getting it setup here:
https://www.boost.org/development/running_regression_tests.html

You can see the results for the master/develop branches here:
https://www.boost.org/development/tests/master/developer/summary.html
https://www.boost.org/development/tests/develop/developer/summary.html

I'm assuming that you would be cross-compiling the tests, this might be a
bit more involved than what is talked about in the setup guide...having to
copy tests to a different platform to run. This has been done in the past
by some android developers, although their results aren't in the test
matrix anymore. I think they were using this script to run:
https://github.com/crystax/android-platform-ndk/blob/master/tests/run-boost-tests

Good luck!
Tom

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: Current Guidance on Compiler Warnings?

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
Am 19.11.2018 um 20:20 schrieb Brian Kuhl via Boost:

> Many of our customers make certified systems ( Planes, Trains, Medical
> Equipment, Factory Automation, etc. ) and the trend in theses industries is
> to be pedantic about eliminating all compiler warnings.

I run our in-house Boost distribution with the same policy (geared
towards Visual Studio). It took me tons of work over several years to
get there but during the process of auditing every warning (and dealing
with it one way or the other) I actually found errors. Beyond that, the
tests have to pass not only in debug build like the test matrix does but
also in release build, plus both 32 bit and 64 bit. Each one of the four
modes exhibits different sets of warnings and errors in some libraries.
Some libraries are poster-childs of careful programming, others - even
new ones - less so.

That may sound egregious but this is how we develop our software for
industrial QA machines.

Ciao
  Dani

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: Current Guidance on Compiler Warnings?

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
I agree with you, I understand the desire of the industry to institute
demonstrable measures of quality in the face of mounting costs associated
with certifying code. Or should I say, the increasing size and complexity
of code that they want to certify. But the result is often a cast that is
placed without good understanding of the context.  I'd love to see more
emphasis tools like coverity, klockwork, that look for less obvious issues,
and languages like Rust that avoid common issues with more rigorous
syntax.  At least with boost.org we have the benefit of some very good
maintainers to act as gatekeepers and avoid the worst of these uninformed
revision.


On Mon, 19 Nov 2018 at 15:03, Emil Dotchevski via Boost <
[hidden email]> wrote:

> On Mon, Nov 19, 2018 at 11:21 AM Brian Kuhl via Boost <
> [hidden email]>
> wrote:
> >
> > I'd like to confirm the guidance on Warnings I find here
> > https://svn.boost.org/trac10/wiki/Guidelines/WarningsGuidelines
> > is still considered current?
> >
> > context ...
> >
> > At Wind River we are in the process of working with Boost 1.68 and
> VxWorks
> > 7 (with Dinkum 7.00  with and Clang  6.0 for ARM and IA boards and  GCC
> 8.1
> > for PowerPC ) with the hope of bundling Boost with our product.
> >
> > Many of our customers make certified systems ( Planes, Trains, Medical
> > Equipment, Factory Automation, etc. ) and the trend in theses industries
> is
> > to be pedantic about eliminating all compiler warnings.
>
> In that context there are probably legal reason for zero-warning policy,
> but it is not true that lack of warnings means fewer errors, in fact it
> could easily lead to more errors. For example warnings about implicit
> conversions are frequently "fixed" by replacing the implicit conversion
> with explicit conversion (cast). But the two are semantically very
> different, and therefore one of them is incorrect, and very likely that is
> the explicit one.
>
> _______________________________________________
> Unsubscribe & other changes:
> http://lists.boost.org/mailman/listinfo.cgi/boost
>

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: Current Guidance on Compiler Warnings?

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
Hi Daniela,

> On 20. Nov 2018, at 20:14, Daniela Engert via Boost <[hidden email]> wrote:
>
> Am 19.11.2018 um 20:20 schrieb Brian Kuhl via Boost:
>
>> Many of our customers make certified systems ( Planes, Trains, Medical
>> Equipment, Factory Automation, etc. ) and the trend in theses industries is
>> to be pedantic about eliminating all compiler warnings.
>
> I run our in-house Boost distribution with the same policy (geared
> towards Visual Studio). It took me tons of work over several years to
> get there but during the process of auditing every warning (and dealing
> with it one way or the other) I actually found errors. Beyond that, the
> tests have to pass not only in debug build like the test matrix does but
> also in release build, plus both 32 bit and 64 bit. Each one of the four
> modes exhibits different sets of warnings and errors in some libraries.
> Some libraries are poster-childs of careful programming, others - even
> new ones - less so.
>
> That may sound egregious but this is how we develop our software for
> industrial QA machines.

just for my curiosity, are you regularly merging these changes back upstream into Boost or do you maintain a list of patches to apply to each new Boost release?

Best regards,
Hans

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: Current Guidance on Compiler Warnings?

Boost - Dev mailing list
Am 21.11.2018 um 09:48 schrieb Hans Dembinski via Boost:

Hi Hans!

> just for my curiosity, are you regularly merging these changes back upstream into Boost or do you maintain a list of patches to apply to each new Boost release?

Both. Pushing upstream depends on my impression about how welcome
warning-related changes are. Error-related changes are pushed
immediately, ofcoz.

Ciao
  Dani

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: Current Guidance on Compiler Warnings?

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
The ideal is always to upstream,  I've done a bit of that it past. Other
patches carry forward, but we certainly don't  "try" to do that. When you
bundle open source you become focused on the release you've bundled and
rest of the world moves on. We are not like a big Linux distro that grabs
every new release. Upstreaming then requires moving your "fix" to the head
of the tree, and working with the maintainer to make sure it's portable and
generic and follows projects conventions. That takes time and effort, and
sometimes get's stalled in the "business" priority queue.    I'm speaking
here of the primarily of proprietary VxWorks and Boost effort, Wind River
also has other products where the focus is different; and virtually the
whole product is "open" e.g. https://www.starlingx.io/ and the "value
proposition" for customers is different.

On Wed, 21 Nov 2018 at 03:47, Hans Dembinski via Boost <
[hidden email]> wrote:

> Hi Daniela,
>
> > On 20. Nov 2018, at 20:14, Daniela Engert via Boost <
> [hidden email]> wrote:
> >
> > Am 19.11.2018 um 20:20 schrieb Brian Kuhl via Boost:
> >
> >> Many of our customers make certified systems ( Planes, Trains, Medical
> >> Equipment, Factory Automation, etc. ) and the trend in theses
> industries is
> >> to be pedantic about eliminating all compiler warnings.
> >
> > I run our in-house Boost distribution with the same policy (geared
> > towards Visual Studio). It took me tons of work over several years to
> > get there but during the process of auditing every warning (and dealing
> > with it one way or the other) I actually found errors. Beyond that, the
> > tests have to pass not only in debug build like the test matrix does but
> > also in release build, plus both 32 bit and 64 bit. Each one of the four
> > modes exhibits different sets of warnings and errors in some libraries.
> > Some libraries are poster-childs of careful programming, others - even
> > new ones - less so.
> >
> > That may sound egregious but this is how we develop our software for
> > industrial QA machines.
>
> just for my curiosity, are you regularly merging these changes back
> upstream into Boost or do you maintain a list of patches to apply to each
> new Boost release?
>
> Best regards,
> Hans
>
> _______________________________________________
> Unsubscribe & other changes:
> http://lists.boost.org/mailman/listinfo.cgi/boost
>

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: Current Guidance on Compiler Warnings?

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
On November 19, 2018 4:01:45 PM EST, Edward Diener via Boost <[hidden email]> wrote:

>
> Warning free is a nice ideal, but the truth is more complicated. Many
> warnings are not really about possible coding mishaps but about a sort
> of lint-like standard which compilers now want to enforce and have
> nothing to do with correct C++ code. Other warnings are simply
> erroneous, as is prevalent most everywhere in the current default VC++
>  preprocessor. Eliminate even the first class of warnings is often a
> fool's errand AFAIAC. All one ends up doing is adding completely
> unnecessary code restrictions to what is perfectly acceptable C++
> code.

That's a broad claim not generally borne out in my experience.

> A typical example is some variable whose name hides a variable in an
> outer scope. This is perfectly acceptable C++ code but now many
> compilers issue a warning when this happens. I object to having to
> worry  about coming up with a unique name to all variables in whatever
> scope in  some translation unit just to avoid such a warning.

That warning is not to enforce some notion of how code should be written. It seeks to highlight a certain class of errors. You may have been certain that the reuse of a name is valid when writing the code, but anyone including you at a later time, may be bitten by a subsequent change to the code.

If an intervening declaration is removed, perhaps unintentionally as the result of other editing, later code referring to that formally reused name will suddenly refer to the earlier declaration. The resulting code may compile, but will surely not be what was intended.

Another error that warning helps with is when a name is reused and a maintainer sees an earlier, but not a latter declaration of the reused identifier. The code may compile, yet not work as the maintainer intended.

You may argue that testing should reveal the resulting problems, but test coverage is rarely so complete as to reliably account for all cases. Renaming the variables will prevent those problems, though you do have to invent unique names.

> This process of
> warnings enforcing coding standards goes on and on and I do not think
> it is possible, or advisable timewise, to spend unnecessary time pleasing
> every compiler's notion of what these lint-like warnings entail. I am
> not against spending time eliminating warnings when the warning itself
> points top some loose use of C++. But I am against spending time on
> eliminating warnings when the warning is just some lint-like alarm
> over  what might be an error but is perfectly normal and
> acceptable C++ code.

Preventing possible errors is a worthwhile goal. Such warnings, at least a subset of them, can be helpful. There are, of course, warnings that border on the ridiculous, but don't ignore the value of the majority.

--
Rob

(Sent from my portable computation device.)

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: Current Guidance on Compiler Warnings?

Boost - Dev mailing list
On 11/21/2018 7:02 PM, Rob Stewart via Boost wrote:

> On November 19, 2018 4:01:45 PM EST, Edward Diener via Boost <[hidden email]> wrote:
>>
>> Warning free is a nice ideal, but the truth is more complicated. Many
>> warnings are not really about possible coding mishaps but about a sort
>> of lint-like standard which compilers now want to enforce and have
>> nothing to do with correct C++ code. Other warnings are simply
>> erroneous, as is prevalent most everywhere in the current default VC++
>>   preprocessor. Eliminate even the first class of warnings is often a
>> fool's errand AFAIAC. All one ends up doing is adding completely
>> unnecessary code restrictions to what is perfectly acceptable C++
>> code.
>
> That's a broad claim not generally borne out in my experience.
>
>> A typical example is some variable whose name hides a variable in an
>> outer scope. This is perfectly acceptable C++ code but now many
>> compilers issue a warning when this happens. I object to having to
>> worry  about coming up with a unique name to all variables in whatever
>> scope in  some translation unit just to avoid such a warning.
>
> That warning is not to enforce some notion of how code should be written. It seeks to highlight a certain class of errors. You may have been certain that the reuse of a name is valid when writing the code, but anyone including you at a later time, may be bitten by a subsequent change to the code.
>
> If an intervening declaration is removed, perhaps unintentionally as the result of other editing, later code referring to that formally reused name will suddenly refer to the earlier declaration. The resulting code may compile, but will surely not be what was intended.

Your response is typical of those programmers who seek a language that
will keep programmers from making mistakes by restrictions on what the
language should allow. That language you seek is not C++ thank god.
Whether the restriction is an actual rule of that language or whether
the restriction is a warning, which others tell me I must eliminate,
makes little difference to me. Try another language like Ada or one of
those many safer languages whose "safe" rules make it much more tedious
to program than C++.

>
> Another error that warning helps with is when a name is reused and a maintainer sees an earlier, but not a latter declaration of the reused identifier. The code may compile, yet not work as the maintainer intended.

That is a red herring. Any code may compile and not do what was intended.

>
> You may argue that testing should reveal the resulting problems, but test coverage is rarely so complete as to reliably account for all cases. Renaming the variables will prevent those problems, though you do have to invent unique names.
>

Sorry, programming in a language where every variable in a TU, even the
most trivial, has to have some utterly unique name in that TU, and whose
names I am expected to all know and keep track of, is not for me.
Torture yourself with such absurdities, in the name of safe programming
no doubt, but I want none of it.

>> This process of
>> warnings enforcing coding standards goes on and on and I do not think
>> it is possible, or advisable timewise, to spend unnecessary time pleasing
>> every compiler's notion of what these lint-like warnings entail. I am
>> not against spending time eliminating warnings when the warning itself
>> points top some loose use of C++. But I am against spending time on
>> eliminating warnings when the warning is just some lint-like alarm
>> over  what might be an error but is perfectly normal and
>> acceptable C++ code.
>
> Preventing possible errors is a worthwhile goal. Such warnings, at least a subset of them, can be helpful. There are, of course, warnings that border on the ridiculous, but don't ignore the value of the majority.

I agree with you that preventing possible errors is a worthwhile goal.
Where we disagree sharply is the tedious elimination of warnings on
perfectly correct code as a path to that prevention. It is a huge waste
of time, and totally unnecessary to boot, to change code to prevent
warnings when the code is correct in doing what it aims to accomplish.
Programmers have much better and harder things to do in the design and
implementation of their ideas and algorithms than to worry about what
any compiler implementation thinks should be a reason for issuing
warnings. I am not saying that all warnings should be unheeded. I am
saying that trying to fix every warning for every compiler, because some
end user insists that he wants to compile with the highest level of
warnings and never see any warnings, is not a practical way of writing
software.

>
> --
> Rob
>
> (Sent from my portable computation device.)



_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: Current Guidance on Compiler Warnings?

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
On 11/19/18 11:20 AM, Brian Kuhl via Boost wrote:

> I'd like to confirm the guidance on Warnings I find here
> https://svn.boost.org/trac10/wiki/Guidelines/WarningsGuidelines
> is still considered current?
>
> context ...
>
> At Wind River we are in the process of working with Boost 1.68 and VxWorks
> 7 (with Dinkum 7.00  with and Clang  6.0 for ARM and IA boards and  GCC 8.1
> for PowerPC ) with the hope of bundling Boost with our product.
>
> Many of our customers make certified systems ( Planes, Trains, Medical
> Equipment, Factory Automation, etc. ) and the trend in theses industries is
> to be pedantic about eliminating all compiler warnings.
>
> While we have not traditionally required zero warnings in open source code
> shipped with our product, there is pressure on us to move in that
> direction, and as result we will probably be contributing pull requests
> specifically to fix or suppress compiler warnings over the coming years.
>
> I'd like to establish clear guidelines for my team as to what is an
> appropriate "coding standard" for Boost in regards to compiler warnings.
> While it is simple to say, everything displayed by -Wall, in practice there
> are many edge cases,  e.g. is an unused parameter acceptable in test code?
> So I'd like to get the maintainers guidance.
>

 From my perspective, this would be OK.  OK - one changes some perfectly
fine code to address a warning so we have easily verifiable "clean"
code. It's just a little BS to keep everyone happy and it does help find
some errors.  When one makes code for multiple compilers - it's a whole
'nuther ball game.  to make one's code pass warning free in such an
environment ends up cluttering the code with lots of ... clutter.
Remember we've got libraries support dozens of compilers - counting
previous versions.  In this environment, it's a fools errand.

Robert Ramey


_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: Current Guidance on Compiler Warnings?

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
On Wed, Nov 21, 2018 at 5:01 PM Edward Diener via Boost <
[hidden email]> wrote:
> I agree with you that preventing possible errors is a worthwhile goal.
> Where we disagree sharply is the tedious elimination of warnings on
> perfectly correct code as a path to that prevention. It is a huge waste
> of time, and totally unnecessary to boot, to change code to prevent
> warnings when the code is correct in doing what it aims to accomplish.

It's actually worse than that, enforcing warning-free compilation leads to
bugs.

First, any change in a correct program can introduce a new bug. Secondly,
"fixing" a warning often alters the semantics of the operation in a subtle
way. Consider for example the use of an explicit cast to silence a warning
that an implicit conversion may lead to something bad. You may think that
all you've done is silence the warning, but in fact you've changed the
program semantically: it no longer does an implicit type conversion,
instead it does an explicit one. And the thing is, one of the two is
incorrect.

Now, if your programmers don't understand how implicit type conversions
work in C++, it is possible that enforcing warning-free compilation avoids
more bugs than it causes. If that's the case, there's no argument.

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
1234 ... 6