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
