On Fri, Oct 6, 2017 at 12:30 PM, Richard Damon <rich...@damon-family.org> 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 <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 >> > > > -- > 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