It would seem that in most cases, we want #if ...
instead of #if defined(...)
, so let’s make sure that when we say #if defined(...)
, we actually mean it.
Inspiration: https://github.com/bitcoin/bitcoin/pull/16344
It would seem that in most cases, we want #if ...
instead of #if defined(...)
, so let’s make sure that when we say #if defined(...)
, we actually mean it.
Inspiration: https://github.com/bitcoin/bitcoin/pull/16344
bitcoin_config.h
and found a few of these.
#if defined(HAVE_O_CLOEXEC)
, which we are defining to 0
on systems without it - this leads to a build failure, and should be fixed.
On the master branch @ 4e8a7654f623fc0dad933b3d93dc54d8206c605d plus #27696, there are only two cases in our build system of explicit unconditional usage of the AC_DEFINE
and AC_DEFINE_UNQUOTED
macros (except for one which define string literals like COPYRIGHT_YEAR
):
That means that the HAVE_FDATASYNC
and HAVE_O_CLOEXEC
are always defined, and them with #if defined(...)
is meaningless. All our code base uses #if ...
for them.
All other use cases of the AC_DEFINE
and AC_DEFINE_UNQUOTED
macros are conditional with explicitly provided value 1
. That means either a macro is defined and expands to 1
or it is not defined. Therefore, both #if ...
and #if defined(...)
behave equally. However, we mean the latter.
Moreover, descriptions like “Define to 1 to enable wallet functions” should be replaced with “Define this symbol to enable wallet functions” as the actual value of the defined macro does not matter at all.
The bottom line:
in most cases, we want
#if ...
instead of#if defined(...)
, so let’s make sure that when we say#if defined(...)
, we actually mean it.
These cases are HAVE_FDATASYNC
and HAVE_O_CLOEXEC
only, which are OK now.
It is worth mentioning that macros like AC_CHECK_DECLS
define always define symbols implicitly.
I don’t think any changes in the source files are required. However, in Developer Notes, we can recommend to use #if defined(...)
by default except for cases when #if ...
is required.