On Fri, Oct 6, 2017 at 12:30 PM, Richard Damon <[email protected]>
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 <[email protected]>
>> wrote:
>>
>> On 10/5/17 8:06 PM, James K. Lowden wrote:
>>>
>>> On Fri, 29 Sep 2017 16:55:05 -0400
>>>> Igor Korot <[email protected]> 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
>>> [email protected]
>>> http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
>>>
>>> _______________________________________________
>> sqlite-users mailing list
>> [email protected]
>> http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
>>
>
>
> --
> Richard Damon
>
> _______________________________________________
> sqlite-users mailing list
> [email protected]
> http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
>
_______________________________________________
sqlite-users mailing list
[email protected]
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
