On Fri, Oct 6, 2017 at 12:30 PM, Richard Damon
wrote:
> If a given macro is sometimes tested with #if defined(FOO) and other times
> with #if FOO, then that would be an error unless it is intended that the
> two respond differently to a #define FOO 0 statement (perhaps to enable but
> not adverti
If a given macro is sometimes tested with #if defined(FOO) and other
times with #if FOO, then that would be an error unless it is intended
that the two respond differently to a #define FOO 0 statement (perhaps
to enable but not advertise an option).
My comments were about reasons why it makes
Fixing the #if is only like 1-5% of the warnings he's complaining
about...
A large chunk of them are around comple options strings used for pragma
compileoptions
--
static const char * const azCompileOpt[] = {
/* These macros are provided to "stringify" the value of the define
** for t
On 10/5/17 8:06 PM, James K. Lowden wrote:
On Fri, 29 Sep 2017 16:55:05 -0400
Igor Korot wrote:
But then why not give it some default value ("0" maybe") and default
it to "1" only if needed during configure?
Because complexity. It takes effort --- unnecessary effort -- to set
up that default
On Fri, 29 Sep 2017 16:55:05 -0400
Igor Korot wrote:
> But then why not give it some default value ("0" maybe") and default
> it to "1" only if needed during configure?
Because complexity. It takes effort --- unnecessary effort -- to set
up that default. That effort could introduce an error, w
On Fri, Sep 29, 2017 at 5:12 PM, Richard Damon
wrote:
> On 9/29/17 2:58 PM, J Decker wrote:
>
>> 20 warnings “cast discards __attribute__((noreturn))” like:
>>>
>>> SQLite3.c:55734:10: warning: cast discards ‘__attribute__((noreturn))’
>>> qualifier from pointer target type [-Wcast-qual]
>>>
On 9/29/17 2:58 PM, J Decker wrote:
20 warnings “cast discards __attribute__((noreturn))” like:
SQLite3.c:55734:10: warning: cast discards ‘__attribute__((noreturn))’
qualifier from pointer target type [-Wcast-qual]
memcpy((void*)&aHdr[1], (const void*)&pWal->hdr, sizeof(WalIndexHdr));
768
On Fri, 29 Sep 2017, Denis V. Razumovsky wrote:
In this very thread there is a warning from GCC about
#if SQLITE_4_BYTE_ALIGNED_MALLOC
What can be wrong for _any_ of the compilers if you will define
SQLITE_4_BYTE_ALIGNED_MALLOC as 0 in sqlite3.h? It's so simple. I think
it should only get bet
Simon,
On Fri, Sep 29, 2017 at 4:38 PM, Simon Slavin wrote:
>
>
> On 29 Sep 2017, at 9:06pm, Denis V. Razumovsky wrote:
>
>> What can be wrong for _any_ of the compilers if you will define
>> SQLITE_4_BYTE_ALIGNED_MALLOC as 0 in sqlite3.h? It's so simple. I think
>> it should only get better for
On 29 Sep 2017, at 9:06pm, Denis V. Razumovsky wrote:
> What can be wrong for _any_ of the compilers if you will define
> SQLITE_4_BYTE_ALIGNED_MALLOC as 0 in sqlite3.h? It's so simple. I think
> it should only get better for all platforms and compilers )
If SQLITE_4_BYTE_ALIGNED_MALLOC always
On 29.09.2017 22:33, Scott Robison wrote:
> On Fri, Sep 29, 2017 at 1:20 PM, Bob Friesenhahn
> wrote:
>> > On Fri, 29 Sep 2017, Scott Robison wrote:
>>> >>
>>> >>
>>> >> The problem is that there is no one best practice for resolving all
>>> >> such warnings in a way that makes all compilers happ
Many thanks to Mr. J Decker. I'm glad if I've made anybody think about
that warnings. My mission is complete if it's true.
On 29.09.2017 21:58, J Decker wrote:
> On Fri, Sep 29, 2017 at 1:07 AM, Denis V. Razumovsky wrote:
>
>> Please remove multiple warnings from compiler about optimisation,
>> v
I am absolutely sure that sqlite is one of the best and the most tested
software product in the nature and having such a point of view I was
rather surprised at number of warnings coming from the compiler. I have
no plans to thrust my opinion on the community, just to draw attention
to the detail
On Fri, Sep 29, 2017 at 1:20 PM, Bob Friesenhahn
wrote:
> On Fri, 29 Sep 2017, Scott Robison wrote:
>>
>>
>> The problem is that there is no one best practice for resolving all
>> such warnings in a way that makes all compilers happy. It is possible
>> to fix all the warnings for one platform, the
On Fri, 29 Sep 2017, Scott Robison wrote:
The problem is that there is no one best practice for resolving all
such warnings in a way that makes all compilers happy. It is possible
to fix all the warnings for one platform, then move on to the next
platform and fix all its warnings, and return to
On Fri, Sep 29, 2017 at 11:58 AM, J Decker wrote:
>
>
> On Fri, Sep 29, 2017 at 1:07 AM, Denis V. Razumovsky wrote:
>
>>
>> SQLite3.c:55734:10: warning: cast discards ‘__attribute__((noreturn))’
>> qualifier from pointer target type [-Wcast-qual]
>>memcpy((void*)&aHdr[1], (const void*)&pWal-
On Fri, Sep 29, 2017 at 1:07 AM, Denis V. Razumovsky wrote:
> Please remove multiple warnings from compiler about optimisation,
> variable conversion, signed overflow and many more potential errors.
>
> 1. Optimisation solutions from GCC:
> If you would like to add extra warning attributes to com
On 29 Sep 2017, at 6:14pm, Denis V. Razumovsky wrote:
> Rule 10: All code must be compiled, from the first day of development,
> with all compiler warnings enabled at the most
> pedantic setting available. All code must compile without warnings.
NASA's code is developed to run on one platform
On Fri, Sep 29, 2017 at 11:14 AM, Denis V. Razumovsky wrote:
> I would like to draw attention to the document: "The Power of 10: Rules
> for Developing Safety-Critical Code" from NASA/JPL Laboratory.
> https://en.wikipedia.org/wiki/The_Power_of_10:_Rules_for_Developing_Safety-Critical_Code
The p
On 9/29/17, Jens Alfke wrote:
>
> it’s not a good idea to walk into a community and
> immediately tell everyone that they’re doing things the wrong way
It's worse than that. The very first sentence we heard from Mr.
Razumovsky was an imperative: "Remove warnings!". And though he did
at least sa
> On Sep 29, 2017, at 10:14 AM, Denis V. Razumovsky wrote:
>
> I would like to draw attention to the document: "The Power of 10: Rules
> for Developing Safety-Critical Code" from NASA/JPL Laboratory.
> https://en.wikipedia.org/wiki/The_Power_of_10:_Rules_for_Developing_Safety-Critical_Code
>
I would like to draw attention to the document: "The Power of 10: Rules
for Developing Safety-Critical Code" from NASA/JPL Laboratory.
https://en.wikipedia.org/wiki/The_Power_of_10:_Rules_for_Developing_Safety-Critical_Code
They tells, for example:
Rule 10: All code must be compiled, from the
> On Sep 29, 2017, at 1:07 AM, Denis V. Razumovsky wrote:
>
> Please remove multiple warnings from compiler about optimisation,
> variable conversion, signed overflow and many more potential errors.
This comes up a lot. SQLite is incredibly thoroughly tested* and
performance-tuned, but the de
Please remove multiple warnings from compiler about optimisation,
variable conversion, signed overflow and many more potential errors.
1. Optimisation solutions from GCC:
If you would like to add extra warning attributes to compile SQLite with
gcc (and many others modern compilers) you will see th
24 matches
Mail list logo