Please remove multiple warnings from compiler about optimisation, variable conversion, signed overflow and many more potential errors.

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
24 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Re: Please remove multiple warnings from compiler about optimisation, variable conversion, signed overflow and many more potential errors.

Richard Damon
On 10/5/17 8:06 PM, James K. Lowden wrote:

> On Fri, 29 Sep 2017 16:55:05 -0400
> Igor Korot <[hidden email]> 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, whereas no
> effort *cannot* introduce an error.  Less is more.
>
> The assumption on the part of the guideline authors seems to be that if
> something is undefined, it might have been overlooked, and the best way
> to make sure it's not overlooked is by ensuring there's always an
> explicit definition.  That's a debatable proposition.  The mere fact
> something is defined in no wise ensures it is defined correctly.
>
> In this case, the tools themselves provide the definition.  For those
> that do, the code compiles one way.  For those that do not, another
> way.  It's entirely automatic.  How could supplying those definitions
> manually be an improvement?
>
> --jkl
I agree here. You could add a

#ifndef FOO
#define FOO 0
#endif

but that adds no safety to the program, as all it does is suppress the
error without needing any thought, so doesn't force you to think about
the option.

By NOT adding such code, you have the option to enable such a warning,
giving you a list of all the option macros that you might want to think
of. You could then add the defines to 1 or 0 as needed in your config.
With the code to force a default, you would need to look through all the
code, make a list of all the option macros used, then see if there are
unconditional defines for them (perhaps they are always given a value,
possibly based on other conditions. Leaving them undefined and letting
the warning trigger is a help here.

--
Richard Damon

_______________________________________________
sqlite-users mailing list
[hidden email]
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
Reply | Threaded
Open this post in threaded view
|

Re: Please remove multiple warnings from compiler about optimisation, variable conversion, signed overflow and many more potential errors.

J Decker
Fixing the #if <symbol> 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 those options in which the value is meaningful. */
#define CTIMEOPT_VAL_(opt) #opt
#define CTIMEOPT_VAL(opt) CTIMEOPT_VAL_(opt)

#if SQLITE_32BIT_ROWID
  "32BIT_ROWID",
#endif
#if SQLITE_4_BYTE_ALIGNED_MALLOC
  "4_BYTE_ALIGNED_MALLOC",
#endif
#if SQLITE_CASE_SENSITIVE_LIKE
  "CASE_SENSITIVE_LIKE",
#endif

----------

Which in that location I would think it should be 'if defined()' the
previous usage of that symbol is #ifdef

kinda like SQLITE_CASE_SENSITIVE_LIKE  which for compileoptions is #if  and
everywhere else is  #ifdef  SQLITE_CASE_SENSITIVE_LIKE.

So it could be defined, as no value, just defined, and enabled for the
compilation, but wouldn't show as a compiled option.

kinda looks like all those are actually bad.  But that's not 217 of
those...




On Thu, Oct 5, 2017 at 6:59 PM, Richard Damon <[hidden email]>
wrote:

> On 10/5/17 8:06 PM, James K. Lowden wrote:
>
>> On Fri, 29 Sep 2017 16:55:05 -0400
>> Igor Korot <[hidden email]> 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, whereas no
>> effort *cannot* introduce an error.  Less is more.
>>
>> The assumption on the part of the guideline authors seems to be that if
>> something is undefined, it might have been overlooked, and the best way
>> to make sure it's not overlooked is by ensuring there's always an
>> explicit definition.  That's a debatable proposition.  The mere fact
>> something is defined in no wise ensures it is defined correctly.
>>
>> In this case, the tools themselves provide the definition.  For those
>> that do, the code compiles one way.  For those that do not, another
>> way.  It's entirely automatic.  How could supplying those definitions
>> manually be an improvement?
>>
>> --jkl
>>
> I agree here. You could add a
>
> #ifndef FOO
> #define FOO 0
> #endif
>
> but that adds no safety to the program, as all it does is suppress the
> error without needing any thought, so doesn't force you to think about the
> option.
>
> By NOT adding such code, you have the option to enable such a warning,
> giving you a list of all the option macros that you might want to think of.
> You could then add the defines to 1 or 0 as needed in your config. With the
> code to force a default, you would need to look through all the code, make
> a list of all the option macros used, then see if there are unconditional
> defines for them (perhaps they are always given a value, possibly based on
> other conditions. Leaving them undefined and letting the warning trigger is
> a help here.
>
> --
> Richard Damon
>
>
> _______________________________________________
> sqlite-users mailing list
> [hidden email]
> http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
>
_______________________________________________
sqlite-users mailing list
[hidden email]
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
Reply | Threaded
Open this post in threaded view
|

Re: Please remove multiple warnings from compiler about optimisation, variable conversion, signed overflow and many more potential errors.

Richard Damon
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 sense to have options that
are checked with #if FOO without adding code to automatically do a
#define FOO 0 if no define was provided by the user.

On 10/6/17 12:17 AM, J Decker wrote:

> Fixing the #if <symbol> 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 those options in which the value is meaningful. */
> #define CTIMEOPT_VAL_(opt) #opt
> #define CTIMEOPT_VAL(opt) CTIMEOPT_VAL_(opt)
>
> #if SQLITE_32BIT_ROWID
>    "32BIT_ROWID",
> #endif
> #if SQLITE_4_BYTE_ALIGNED_MALLOC
>    "4_BYTE_ALIGNED_MALLOC",
> #endif
> #if SQLITE_CASE_SENSITIVE_LIKE
>    "CASE_SENSITIVE_LIKE",
> #endif
>
> ----------
>
> Which in that location I would think it should be 'if defined()' the
> previous usage of that symbol is #ifdef
>
> kinda like SQLITE_CASE_SENSITIVE_LIKE  which for compileoptions is #if  and
> everywhere else is  #ifdef  SQLITE_CASE_SENSITIVE_LIKE.
>
> So it could be defined, as no value, just defined, and enabled for the
> compilation, but wouldn't show as a compiled option.
>
> kinda looks like all those are actually bad.  But that's not 217 of
> those...
>
>
>
>
> On Thu, Oct 5, 2017 at 6:59 PM, Richard Damon <[hidden email]>
> wrote:
>
>> On 10/5/17 8:06 PM, James K. Lowden wrote:
>>
>>> On Fri, 29 Sep 2017 16:55:05 -0400
>>> Igor Korot <[hidden email]> 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, whereas no
>>> effort *cannot* introduce an error.  Less is more.
>>>
>>> The assumption on the part of the guideline authors seems to be that if
>>> something is undefined, it might have been overlooked, and the best way
>>> to make sure it's not overlooked is by ensuring there's always an
>>> explicit definition.  That's a debatable proposition.  The mere fact
>>> something is defined in no wise ensures it is defined correctly.
>>>
>>> In this case, the tools themselves provide the definition.  For those
>>> that do, the code compiles one way.  For those that do not, another
>>> way.  It's entirely automatic.  How could supplying those definitions
>>> manually be an improvement?
>>>
>>> --jkl
>>>
>> I agree here. You could add a
>>
>> #ifndef FOO
>> #define FOO 0
>> #endif
>>
>> but that adds no safety to the program, as all it does is suppress the
>> error without needing any thought, so doesn't force you to think about the
>> option.
>>
>> By NOT adding such code, you have the option to enable such a warning,
>> giving you a list of all the option macros that you might want to think of.
>> You could then add the defines to 1 or 0 as needed in your config. With the
>> code to force a default, you would need to look through all the code, make
>> a list of all the option macros used, then see if there are unconditional
>> defines for them (perhaps they are always given a value, possibly based on
>> other conditions. Leaving them undefined and letting the warning trigger is
>> a help here.
>>
>> --
>> Richard Damon
>>
>>
>> _______________________________________________
>> sqlite-users mailing list
>> [hidden email]
>> http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
>>
> _______________________________________________
> sqlite-users mailing list
> [hidden email]
> http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users


--
Richard Damon

_______________________________________________
sqlite-users mailing list
[hidden email]
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
Reply | Threaded
Open this post in threaded view
|

Re: Please remove multiple warnings from compiler about optimisation, variable conversion, signed overflow and many more potential errors.

J Decker
On Fri, Oct 6, 2017 at 12:30 PM, Richard Damon <[hidden email]>
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 advertise an option).
>
> My comments were about reasons why it makes sense to have options that are
> checked with #if FOO without adding code to automatically do a #define FOO
> 0 if no define was provided by the user.
>

Which would break most cases... it would show under pragma comiple_options
no options, and yet end up using a whole bunch of options in the code.


>
> On 10/6/17 12:17 AM, J Decker wrote:
>
>> Fixing the #if <symbol> 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 those options in which the value is meaningful. */
>> #define CTIMEOPT_VAL_(opt) #opt
>> #define CTIMEOPT_VAL(opt) CTIMEOPT_VAL_(opt)
>>
>> #if SQLITE_32BIT_ROWID
>>    "32BIT_ROWID",
>> #endif
>> #if SQLITE_4_BYTE_ALIGNED_MALLOC
>>    "4_BYTE_ALIGNED_MALLOC",
>> #endif
>> #if SQLITE_CASE_SENSITIVE_LIKE
>>    "CASE_SENSITIVE_LIKE",
>> #endif
>>
>> ----------
>>
>> Which in that location I would think it should be 'if defined()' the
>> previous usage of that symbol is #ifdef
>>
>> kinda like SQLITE_CASE_SENSITIVE_LIKE  which for compileoptions is #if
>> and
>> everywhere else is  #ifdef  SQLITE_CASE_SENSITIVE_LIKE.
>>
>> So it could be defined, as no value, just defined, and enabled for the
>> compilation, but wouldn't show as a compiled option.
>>
>> kinda looks like all those are actually bad.  But that's not 217 of
>> those...
>>
>>
>>
>>
>> On Thu, Oct 5, 2017 at 6:59 PM, Richard Damon <[hidden email]>
>> wrote:
>>
>> On 10/5/17 8:06 PM, James K. Lowden wrote:
>>>
>>> On Fri, 29 Sep 2017 16:55:05 -0400
>>>> Igor Korot <[hidden email]> 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, whereas no
>>>> effort *cannot* introduce an error.  Less is more.
>>>>
>>>> The assumption on the part of the guideline authors seems to be that if
>>>> something is undefined, it might have been overlooked, and the best way
>>>> to make sure it's not overlooked is by ensuring there's always an
>>>> explicit definition.  That's a debatable proposition.  The mere fact
>>>> something is defined in no wise ensures it is defined correctly.
>>>>
>>>> In this case, the tools themselves provide the definition.  For those
>>>> that do, the code compiles one way.  For those that do not, another
>>>> way.  It's entirely automatic.  How could supplying those definitions
>>>> manually be an improvement?
>>>>
>>>> --jkl
>>>>
>>>> I agree here. You could add a
>>>
>>> #ifndef FOO
>>> #define FOO 0
>>> #endif
>>>
>>> but that adds no safety to the program, as all it does is suppress the
>>> error without needing any thought, so doesn't force you to think about
>>> the
>>> option.
>>>
>>> By NOT adding such code, you have the option to enable such a warning,
>>> giving you a list of all the option macros that you might want to think
>>> of.
>>> You could then add the defines to 1 or 0 as needed in your config. With
>>> the
>>> code to force a default, you would need to look through all the code,
>>> make
>>> a list of all the option macros used, then see if there are unconditional
>>> defines for them (perhaps they are always given a value, possibly based
>>> on
>>> other conditions. Leaving them undefined and letting the warning trigger
>>> is
>>> a help here.
>>>
>>> --
>>> Richard Damon
>>>
>>>
>>> _______________________________________________
>>> sqlite-users mailing list
>>> [hidden email]
>>> http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
>>>
>>> _______________________________________________
>> sqlite-users mailing list
>> [hidden email]
>> http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
>>
>
>
> --
> Richard Damon
>
> _______________________________________________
> sqlite-users mailing list
> [hidden email]
> http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
>
_______________________________________________
sqlite-users mailing list
[hidden email]
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
12