Re: Compilation warnings in Lua 5.2.1 (size_t to unsigned int conversion)

[William Ahern <william@...>]

On Thu, Sep 27, 2012 at 01:48:03PM +0100, liam mail wrote:
> On 27 September 2012 00:35, William Ahern <william@25thandclement.com> wrote:
> > On Wed, Sep 26, 2012 at 11:44:15AM -0600, William Sumner wrote:
> >> On Sep 26, 2012, at 11:34 AM, William Ahern <william@25thandClement.com> wrote:
> > <snip>
> >> > That's because clang and GCC are competing to add the most obnoxious
> >> > diagnostics, and the newest version of clang is usually a step or two ahead.
> >> > Just give it one or two releases, and GCC will fall into line.
> >> >
> >> > Eventually they'll both just immediately exit with the diagnostic, "just use
> >> > C++ already if you want to cast so much", and then everybody's heads will
> >> > explode.
> >> >
> >>
> >> Is a default warning about a loss of integer precision that out of line?
> >> At any rate, adding explicit casts to my local copy of Lua's source
> >> resolves the issue.
> >
> > It is when you're dealing with unsigned integers and the warning is by
> > default, or with the very common -Wall (as opposed to -Wextra). It becomes
> > extremely annoying when you're doing bit logic or modulo arithmetic.
> >
> You do realise this is an example of a "common warning" as outlined in
> the C99 Annex? Personally I much prefer a warning to be generated
> rather than not, even if you override it as you know better than the
> compiler.
> 

I disagree. The Annex speaks of implicit narrowing of signed integers,
although the language is loose because it's not part of the standard proper.
But if you grep the entire standard for "narrow" or "narrowing", it's always
in the context of signed integrals.

Anyhow, here's an example of an implicit signed narrowing:

	char foo[1] = 'a';

Would you want a warning for this? Of course not.

Anyhow, point is, at some point people will need to stop equating zero
compiler warnings with good code, because it will (or already has) passed
the point where most compiler diagnostics actually flag high-risk
constructs. Instead, particularly with clang, the diagnostics are just
someone's idea of good coding style, unrelated to the actual prevalance of
bugs.