Re: [sqlite] unreached code in sqlite3.c?

[R.Smith]

On 2/13/2015 9:57 AM, Dominique Devienne wrote:


Warnings are always a tradeoff between pointing out what could be
mistakes/oversights versus senseless noise.

Most times I get the unreachable warning in my code is when I'm actively
coding, experimenting, moving things around, then when I'm done I silence
them one way or another.


D'accord - but it poses an interesting dichotomy: The above is great, 
however in open-source scenarios - compiling someone else's code with 
your new special compiler directives where the compiler then produces 
warnings which shouldn't be warnings - and then requesting the original 
coder to "fix" their code - this can't ever be a useful thing.



Not 100% sure (I don't use Clang day to day), but I think I remember
reading that one way to silence this Clang warning is via extra parens, if
((bool-test)) { ... }. You're telling Clang "this one's not an oversight,
thank you". Small enough concession to having useful warnings in other
places, no? Certainly less ugly than using the preprocessor IMHO. My $0.02.


Sure, but again, having to spend energy after-the-fact on "fixing" code 
that isn't broken - My vote will always be for fixing the compiler.


___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] unreached code in sqlite3.c?

[Dominique Devienne]

On Thu, Feb 12, 2015 at 8:39 PM, Tim Streater  wrote:

> On 12 Feb 2015 at 19:14, R.Smith  wrote:
> > On 2/12/2015 8:50 PM, Doug Currie wrote:
> >> It's easy enough to fix if you want 0 to be a valid value for
> TERM_VNULL:
> >>
> >> #if TERM_VNULL
> >>   if( pTerm->wtFlags & TERM_VNULL ) continue;
> >> #endif
> >
> > Agreed, but how easy it is to fix a problem that is not a problem is
> > kind of irrelevant... We should write code to make systems execute
> > efficiently and correct, not to make compilers shush.
>
> If the statement will never be executed the compiler should simply
> optimise it away. No warning is necessary unless you turn on some flag that
> highlights such optimisations.
>

Warnings are always a tradeoff between pointing out what could be
mistakes/oversights versus senseless noise.

Most times I get the unreachable warning in my code is when I'm actively
coding, experimenting, moving things around, then when I'm done I silence
them one way or another.

Not 100% sure (I don't use Clang day to day), but I think I remember
reading that one way to silence this Clang warning is via extra parens, if
((bool-test)) { ... }. You're telling Clang "this one's not an oversight,
thank you". Small enough concession to having useful warnings in other
places, no? Certainly less ugly than using the preprocessor IMHO. My $0.02.
--DD
___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] unreached code in sqlite3.c?

[Eric Minbiole]

> If the statement will never be executed the compiler should simply optimise 
> it away. No warning is necessary unless you turn on some flag that highlights 
> such optimisations. 

Per the original post, I believe that the warning was expressly enabled using 
the [-Wunreachable-code] compiler flag. In this case, I’d argue that the 
compiler is doing expressly what it was instructed to do.

~Eric
___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] unreached code in sqlite3.c?

[Tim Streater]

On 12 Feb 2015 at 19:14, R.Smith  wrote: 

> On 2/12/2015 8:50 PM, Doug Currie wrote:

>> It's easy enough to fix if you want 0 to be a valid value for TERM_VNULL:
>>
>> #if TERM_VNULL
>>   if( pTerm->wtFlags & TERM_VNULL ) continue;
>> #endif
>
> Agreed, but how easy it is to fix a problem that is not a problem is
> kind of irrelevant... We should write code to make systems execute
> efficiently and correct, not to make compilers shush.

If the statement will never be executed the compiler should simply optimise it 
away. No warning is necessary unless you turn on some flag that highlights such 
optimisations. 

--
Cheers  --  Tim
___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] unreached code in sqlite3.c?

[R.Smith]

On 2/12/2015 8:50 PM, Doug Currie wrote:

On Thu, Feb 12, 2015 at 1:35 PM, R.Smith  wrote:


Now one could argue the warning should not be issued for it, or some
warnings are fine as information. Personally I prefer zero unneeded
warnings/clutter but that's just my pedantism.


My pedantism is to prefer the warning since it might catch cases where the
code inadvertently neglects to define TERM_VNULL at all.


Apologies, you misunderstand me - I am of course fully in agreement with 
showing the warning for valid non-executes, my point was that it is 
quite easy for the compiler to realize the if term depends on a prior 
symbol - it is not complicated and I believe it previously got this 
right - it should do it right.


And if something /IS/ too complicated to understand, then one shouldn't 
reserve an opinion on it - even if you are a C compiler.



It's easy enough to fix if you want 0 to be a valid value for TERM_VNULL:

#if TERM_VNULL
  if( pTerm->wtFlags & TERM_VNULL ) continue;
#endif


Agreed, but how easy it is to fix a problem that is not a problem is 
kind of irrelevant... We should write code to make systems execute 
efficiently and correct, not to make compilers shush.


If the warning feature starts crying wolf - it ceases to be a feature.

Anyway, enough armchair musings from me, I am sure the clang compiler 
designers agree with all the above, I doubt they will have a long 
argument about why the current way is best, it's probably really just a 
simple bug/oversight they might fix in a second if asked to.




___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] unreached code in sqlite3.c?

[Doug Currie]

On Thu, Feb 12, 2015 at 1:35 PM, R.Smith  wrote:

>
> Now one could argue the warning should not be issued for it, or some
> warnings are fine as information. Personally I prefer zero unneeded
> warnings/clutter but that's just my pedantism.
>

My pedantism is to prefer the warning since it might catch cases where the
code inadvertently neglects to define TERM_VNULL at all.

It's easy enough to fix if you want 0 to be a valid value for TERM_VNULL:

#if TERM_VNULL
 if( pTerm->wtFlags & TERM_VNULL ) continue;
#endif

e
___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] unreached code in sqlite3.c?

[R.Smith]

On 2/12/2015 4:58 PM, Doug Currie wrote:

Well, if TERM_VNULL is 0, then the code is truly unreachable, so I wouldn't
call it a compiler bug.

e


The point is that TERM_VNULL is controlled by a compiler pre-processor 
switch and is only unreachable for specific values of that switch - 
hence if the clang compiler does not understand this (a convention that 
is used all the time through all sourcecode in the World) then it is a 
bug in the compiler, or at the very least, a rather glaring 
misapprehension.  Whether the end result evaluates to true for some 
specific switch value is irrelevant.


Now one could argue the warning should not be issued for it, or some 
warnings are fine as information. Personally I prefer zero unneeded 
warnings/clutter but that's just my pedantism.



___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] unreached code in sqlite3.c?

[Doug Currie]

Well, if TERM_VNULL is 0, then the code is truly unreachable, so I wouldn't
call it a compiler bug.

e


On Thu, Feb 12, 2015 at 9:26 AM, Richard Hipp  wrote:

> Dan is right.  I think I'd calling this a clang bug.
> On Feb 12, 2015 9:06 AM, "Dan Kennedy"  wrote:
>
> > On 02/12/2015 09:02 PM, Jens Miltner wrote:
> >
> >> Hi,
> >>
> >> I'm getting the following two warnings when compiling sqlite3.c with the
> >> latest clang tools:
> >>
> >>  sqlite3.c:116769:39: warning: code will never be executed
> >>> [-Wunreachable-code]
> >>>  if( pTerm->wtFlags & TERM_VNULL ) continue;
> >>>^~~~
> >>> sqlite3.c:116716:39: warning: code will never be executed
> >>> [-Wunreachable-code]
> >>>  if( pTerm->wtFlags & TERM_VNULL ) continue;
> >>>^~~~
> >>> 2 warnings generated.
> >>>
> >>>  (This is for SQLite version 3.8.8.2).
> >>
> >>
> >>  From the code, I don't immediately see why the compiler would think
> this
> >> code will never be executed, so I thought I'd bring it up with you guys.
> >>
> >
> >
> > Unless you have defined SQLITE_ENABLE_STAT4 (or STAT3), TERM_VNULL is
> > defined as 0:
> >
> >   http://www.sqlite.org/src/artifact/d3633e9b59210324?ln=273-277
> >
> > Dan.
> >
> > ___
> > sqlite-users mailing list
> > sqlite-users@sqlite.org
> > http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
> >
> ___
> sqlite-users mailing list
> sqlite-users@sqlite.org
> http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
>
___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] unreached code in sqlite3.c?

[Richard Hipp]

Dan is right.  I think I'd calling this a clang bug.
On Feb 12, 2015 9:06 AM, "Dan Kennedy"  wrote:

> On 02/12/2015 09:02 PM, Jens Miltner wrote:
>
>> Hi,
>>
>> I'm getting the following two warnings when compiling sqlite3.c with the
>> latest clang tools:
>>
>>  sqlite3.c:116769:39: warning: code will never be executed
>>> [-Wunreachable-code]
>>>  if( pTerm->wtFlags & TERM_VNULL ) continue;
>>>^~~~
>>> sqlite3.c:116716:39: warning: code will never be executed
>>> [-Wunreachable-code]
>>>  if( pTerm->wtFlags & TERM_VNULL ) continue;
>>>^~~~
>>> 2 warnings generated.
>>>
>>>  (This is for SQLite version 3.8.8.2).
>>
>>
>>  From the code, I don't immediately see why the compiler would think this
>> code will never be executed, so I thought I'd bring it up with you guys.
>>
>
>
> Unless you have defined SQLITE_ENABLE_STAT4 (or STAT3), TERM_VNULL is
> defined as 0:
>
>   http://www.sqlite.org/src/artifact/d3633e9b59210324?ln=273-277
>
> Dan.
>
> ___
> sqlite-users mailing list
> sqlite-users@sqlite.org
> http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
>
___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] unreached code in sqlite3.c?

[Dan Kennedy]

On 02/12/2015 09:02 PM, Jens Miltner wrote:

Hi,

I'm getting the following two warnings when compiling sqlite3.c with the latest 
clang tools:


sqlite3.c:116769:39: warning: code will never be executed [-Wunreachable-code]
 if( pTerm->wtFlags & TERM_VNULL ) continue;
   ^~~~
sqlite3.c:116716:39: warning: code will never be executed [-Wunreachable-code]
 if( pTerm->wtFlags & TERM_VNULL ) continue;
   ^~~~
2 warnings generated.


(This is for SQLite version 3.8.8.2).


 From the code, I don't immediately see why the compiler would think this code 
will never be executed, so I thought I'd bring it up with you guys.



Unless you have defined SQLITE_ENABLE_STAT4 (or STAT3), TERM_VNULL is 
defined as 0:


  http://www.sqlite.org/src/artifact/d3633e9b59210324?ln=273-277

Dan.

___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users