unify '#ifdef HAVE_CONFIG_H' declaration

[H5117]

Preparation for introducing Meson.

Created with commands:

$ find . -name '*.h' -exec sed -i 's/#if HAVE_CONFIG_H/#ifdef HAVE_CONFIG_H/g' '{}' \;
$ find . -name '*.c' -exec sed -i 's/#if HAVE_CONFIG_H/#ifdef HAVE_CONFIG_H/g' '{}' \;
$ find . -name '*.m' -exec sed -i 's/#if HAVE_CONFIG_H/#ifdef HAVE_CONFIG_H/g' '{}' \;

Without the patch:

$ grep -rF '#if HAVE_CONFIG_H' | wc -l
107
$ grep -rF '#ifdef HAVE_CONFIG_H' | wc -l
59

With the patch:

$ grep -rF '#if HAVE_CONFIG_H' | wc -l
0
$ grep -rF '#ifdef HAVE_CONFIG_H' | wc -l
166

[frankmorgner]

Isn't #if more desirable, because it will work as expected when HAVE_CONFIG_H is undefined and when it is set to 0? https://gcc.gnu.org/onlinedocs/cpp/If.html:

Identifiers that are not macros, which are all considered to be the number zero. This allows you to write #if MACRO instead of #ifdef MACRO, if you know that MACRO, when defined, will always have a nonzero value. Function-like macros used without their function call parentheses are also treated as zero.

In some contexts this shortcut is undesirable. The -Wundef option causes GCC to warn whenever it encounters an identifier which is not a macro in an ‘#if’.

[Jakuje]

Is there some good use case for setting the HAVE_CONFIG_H to 0?

I would say for this use case, the #ifdef is more appropriate as with #if HAVE_CONFIG_H, when somebody tries to include this file fro different context without this define, it will complain about undefined macro as discussed in the second part of the quote you provided.

[mouse07410]

I remember C compilers failing to compile with an error seeing#if A when A was not defined, and restricted #if form to only set values. To the point that I had to write something like

#if defined(A) && A

It's been a while since I programmed in C, so don't remember clearly.

[H5117]

C compilers failing to compile with an error seeing#if A when A was not defined

This is still actual and I fixed it in several places in #3128.

But now I think that we should just remove HAVE_CONFIG_H from the code. Is there any reason to keep this archaism at all?

[Jakuje]

I still believe it should be there. As discussed for example in amule-project/amule#241 this might be useful for platforms without the config.h. Does the windows build have the config.h?

I see the meson and cmake provide the config.h and they can likely run on windows too so with Meson, this might not be issue.

Similar changes were done in other projects such as https://gitlab.freedesktop.org/pipewire/pipewire/-/merge_requests/748/diffs but I think they should land only after we will be sure the meson works for all the platforms we are interested and after we will remove the autotools.

[frankmorgner]

You could also remove -Wundef from the meson build to fix this.

On Windows, we can build without autoconf (and without config.h). (It is kind of cumbersome to set up initially.) If we push meson so far so that we can replace the autotools, then we can remove the ifdef's, because we will always build with config.h, but for now we should stick with the existing approach.

[frankmorgner]

I just read that the C99 standard also specifies at §6.10.1:

After all replacements due to macro expansion and the defined unary operator have been performed, all remaining identifiers are replaced with the pp-number 0

So I still prefer to use #if rather than #ifdef for HAVE_CONFIG_H and any other similar definition.

[Jakuje]

Regardless it is ok based on the C99 standard, I find the gcc warnings about undefined macros helpful as it can help spotting a mistake/typo. Removing the -Wundef will just hide it.

[frankmorgner]

Making this an implicit rule, would mean to apply this for all the other instances where we are checking for dependencies. We can start here, but should work through the rest of the code at some point.

[Jakuje]

@frankmorgner whats the status of this PR? Are we good with this state or do you want some changes?