Determine which preprocessor defines are used by included library headers

Question

I'm looking at a project which has many preprocessor defines generated in config.h by autotools.

Now, some of these are from earlier versions of the source, and also from parts of it which have been cut out with the source files no longer present. So - some of that file is now useless and should not be generated. The question is - which part?

One thing you can do is search for the use of preprocessor defines in the current project sources. I've done that. But - there are defines which affect other libraries' headers upon inclusion, such as _GNU_SOURCE

My question: How can I determine which defines (including ones which are currently commented-out in the config.h) have a potential on headers included from the sources?

(Of course I need precision over recall here, since a useless #define is not so bad, but a missing define I really need to avoid.)

Interesting problem, but I doubt there's a satisfying solution to it. At least when feature-test macros come to the table, I can't think of a way to know what they were defined for by static analysis. — , May 03 '18 at 09:21
This probably depends a lot on your compiler. For `gcc` you can compile your code with `-E -dM` (instead of `-c`) and that lists you all defines that the preprocessor knows about. — Jens Gustedt, May 03 '18 at 11:52
@FelixPalmen: An imperfect heuristic would still be of much help. — einpoklum, May 03 '18 at 11:57
Not that it helps much *now*, but I'd argue that feature-test macros ought never to be defined directly by the Autotools. The features required by your code are a function of *the code*, not, for the most part, of the environment in which it is built. Therefore, any feature-test macros that need to be explicitly defined should be defined in the sources, and usually unconditionally. — John Bollinger, May 06 '18 at 20:57
I'd suggest leaving the feature-test macros alone, and restricting yourself to cleaning up the macros whose needfulness you can check by examining the project's own sources. Or at least start with that. You could make it a longer-term project to deal with the feature-test macros. — John Bollinger, May 06 '18 at 21:02
Also, don't neglect the compiler as a tool for checking the need for feature-test macros. If you suppress a feature-test macro and your code no longer compiles or the compiler emits warnings about implicit function declarations, then you've certainly discovered that you need that macro. Unfortunately, I'm not confident that the reverse is true. — John Bollinger, May 06 '18 at 21:05
@JohnBollinger: First, some of the defines are not feature test results (e.g. version identifiers). But that aside - while what you say is true, my question is exactly regarding that examination. You see, "the code" also includes the standard library, or some of it. And I would rather not examine all of that code as well. — einpoklum, May 06 '18 at 21:21
@einpoklum, your code *does not* include the standard library unless that is itself your project. My advice to you is in fact to accept and live and work with that. I completely agree that you should not be examining the standard library headers, and you can make a lot of progress without doing so. — John Bollinger, May 07 '18 at 13:13

John Greene · Answer 1 · 2018-08-05T16:37:37.390

Easiest way is to let the autoscan create your configure.scan file then you can cut-n-paste what you need.

$ cd myCproject
$ autoscan
aclocal.m4:16: warning: this file was generated for autoconf 2.63.
You have another version of autoconf.  It may work, but is not guaranteed to.
If you have problems, you may need to regenerate the build system entirely.
To do so, use the procedure documented by the package, typically `autoreconf'.
configure.ac:6: warning: AC_LANG_CONFTEST: no AC_LANG_SOURCE call detected in body
../../lib/autoconf/lang.m4:193: AC_LANG_CONFTEST is expanded from...
../../lib/autoconf/general.m4:2672: _AC_LINK_IFELSE is expanded from...
../../lib/autoconf/general.m4:2689: AC_LINK_IFELSE is expanded from...
aclocal.m4:1037: _LT_SYS_MODULE_PATH_AIX is expanded from...
aclocal.m4:4176: _LT_LINKER_SHLIBS is expanded from...
aclocal.m4:5251: _LT_LANG_C_CONFIG is expanded from...
aclocal.m4:159: _LT_SETUP is expanded from...
aclocal.m4:88: LT_INIT is expanded from...
configure.ac:6: the top level
configure.ac:6: warning: AC_LANG_CONFTEST: no AC_LANG_SOURCE call detected in body
../../lib/autoconf/lang.m4:193: AC_LANG_CONFTEST is expanded from...
../../lib/autoconf/general.m4:2672: _AC_LINK_IFELSE is expanded from...
../../lib/autoconf/general.m4:2689: AC_LINK_IFELSE is expanded from...
aclocal.m4:4176: _LT_LINKER_SHLIBS is expanded from...
aclocal.m4:5251: _LT_LANG_C_CONFIG is expanded from...
aclocal.m4:159: _LT_SETUP is expanded from...
aclocal.m4:88: LT_INIT is expanded from...
configure.ac:6: the top level
configure.ac: warning: missing AC_CHECK_FUNCS([clock_gettime]) wanted by: acs.c:405
configure.ac: warning: missing AC_CHECK_FUNCS([gethrtime]) wanted by: atomicclock.c:52
configure.ac: warning: missing AC_CHECK_FUNCS([gettimeofday]) wanted by: atomicclock.c:99
configure.ac: warning: missing AC_CHECK_HEADERS([mach/mach.h]) wanted by: atomicclock.c:16
configure.ac: warning: missing AC_CHECK_HEADERS([sys/time.h]) wanted by: atomicclock.c:13
configure.ac: warning: missing AC_PROG_CXX wanted by: ltmain.sh:677
configure.ac: warning: missing AC_PROG_RANLIB wanted by: ltmain.sh:1601
configure.ac: warning: missing AC_TYPE_UINT64_T wanted by: acs.c:338
$

At completion, the configure.scan file gets created. An actual example of my personal project is shown as:

AC_PROG_CPP
AC_PROG_INSTALL
AC_PROG_LN_S
AC_PROG_MAKE_SET
AC_PROG_RANLIB

# Checks for libraries.
# FIXME: Replace `main' with a function in `-lrt':
AC_CHECK_LIB([rt], [main])

# Checks for header files.
AC_CHECK_HEADERS([mach/mach.h stdint.h stdlib.h string.h sys/time.h unistd.h])

# Checks for typedefs, structures, and compiler characteristics.
AC_TYPE_UINT32_T
AC_TYPE_UINT64_T

# Checks for library functions.
AC_CHECK_FUNCS([clock_gettime gethrtime gettimeofday])

AC_CONFIG_FILES([Makefile])
AC_CONFIG_SUBDIRS([automake-1.15])
AC_OUTPUT

You can cut-and-paste what you need from the configure.scan and insert it under its appropriate section within your own configure.am (or configure.in) file.

autoscan utility is part of the autoconf package.

Determine which preprocessor defines are used by included library headers

1 Answers1