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 <rich...@damon-family.org>
wrote:
> On 10/5/17 8:06 PM, James K. Lowden wrote:
>
>> On Fri, 29 Sep 2017 16:55:05 -0400
>> Igor Korot <ikoro...@gmail.com> 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
> sqlite-users@mailinglists.sqlite.org
> http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
>
_______________________________________________
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
