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 <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
