Macro definitions for headers, where to put them?

When defining macros that headers rely on, such as _FILE_OFFSET_BITS, FUSE_USE_VERSION, _GNU_SOURCE among others, where is the best place to put them?

Some possibilities I've considered include

1. At the top of the any source files that rely on definitions exposed by headers included in that file
2. Immediately before the include for the relevant header(s)
3. Define at the CPPFLAGS level via the compiler? (such as -D_FILE_OFFSET_BITS=64) for the:
   1. Entire source repo
   2. The whole project
   3. Just the sources that require it
4. In project headers, which s开发者_开发知识库hould also include those relevant headers to which the macros apply
5. Some other place I haven't thought of, but is infinitely superior

A note: Justification by applicability to make, autotools, and other build systems is a factor in my decision.

If the macros affect system headers, they probably ought to go somewhere where they affect every source file that includes those system headers (which includes those that include them indirectly). The most logical place would therefore be on the command line, assuming your build system allows you to set e.g. CPPFLAGS to affect the compilation of every file.

If you use precompiled headers, and have a precompiled header that must therefore be included first in every source file (e.g. stdafx.h for MSVC projects) then you could put them in there too.

For macros that affect self-contained libraries (whether third-party or written by you), I would create a wrapper header that defines the macros and then includes the library header. All uses of the library from your project should then include your wrapper header rather than including the library header directly. This avoids defining macros unnecessarily, and makes it clear that they relate to that library. If there are dependencies between libraries then you might want to make the macros global (in the build system or precompiled header) just to be on the safe side.

Well, it depends.

Most, I'd define via the command line - in a Makefile or whatever build system you use.

As for _FILE_OFFSET_BITS I really wouldn't define it explicitly, but rather use getconf LFS_CFLAGS and getconf LFS_LDFLAGS.

I would always put them on the command line via CPPFLAGS for the whole project. If you put them any other place, there's a danger that you might forget to copy them into a new source file or include a system header before including the project header that defines them, and this could lead to extremely nasty bugs (like one file declaring a legacy 32-bit struct stat and passing its address to a function in another file which expects a 64-bit struct stat).

BTW, it's really ridiculous that _FILE_OFFSET_BITS=64 still isn't the default on glibc.

Most projects that I've seen use them did it via -D command line options. They are there because that eases building the source with different compilers and system headers. If you were to build with a system compiler for another system that didn't need them or needed a different set of them then a configure script can easily change the command line arguments that a make file passes to the compiler.

It's probably best to do it for the entire program because some of the flags effect which version of a function gets brought in or the size/layout of a struct and mixing those up could cause crazy things if you aren't careful.

They certainly are annoying to keep up with.

For _GNU_SOURCE and the autotools in particular, you could use AC_USE_SYSTEM_EXTENSIONS (citing liberally from the autoconf manual here):

-- Macro: AC_USE_SYSTEM_EXTENSIONS
This macro was introduced in Autoconf 2.60. If possible, enable extensions to C or Posix on hosts that normally disable the extensions, typically due to standards-conformance namespace issues. This should be called before any macros that run the C compiler. The following preprocessor macros are defined where appropriate:

_GNU_SOURCE Enable extensions on GNU/Linux.

__EXTENSIONS__ Enable general extensions on Solaris.

_POSIX_PTHREAD_SEMANTICS Enable threading extensions on Solaris.

_TANDEM_SOURCE Enable extensions for the HP NonStop platform.

_ALL_SOURCE Enable extensions for AIX 3, and for Interix.

_POSIX_SOURCE Enable Posix functions for Minix.

_POSIX_1_SOURCE Enable additional Posix functions for Minix.

_MINIX Identify Minix platform. This particular preprocessor macro is obsolescent, and may be removed in a future release of Autoconf.

For _FILE_OFFSET_BITS, you need to call AC_SYS_LARGEFILE and AC_FUNC_FSEEKO:

— Macro: AC_SYS_LARGEFILE

Arrange for 64-bit file offsets, known as large-file support. On some hosts, one must use special compiler options to build programs that can access large files. Append any such options to the output variable CC. Define _FILE_OFFSET_BITS and _LARGE_FILES if necessary.

Large-file support can be disabled by configuring with the --disable-largefile option.

If you use this macro, check that your program works even when off_t is wider than long int, since this is common when large-file support is enabled. For example, it is not correct to print an arbitrary off_t value X with printf("%ld", (long int) X).

The LFS introduced the fseeko and ftello functions to replace their C counterparts fseek and ftell that do not use off_t. Take care to use AC_FUNC_FSEEKO to make their prototypes available when using them and large-file support is enabled.

If you are using autoheader to generate a config.h, you could define the other macros you care about using AC_DEFINE or AC_DEFINE_UNQUOTED:

AC_DEFINE([FUSE_VERSION], [28], [FUSE Version.])

The definition will then get passed to the command line or placed in config.h, if you're using autoheader. The real benefit of AC_DEFINE is that it easily allows preprocessor definitions as a result of configure checks and separates system-specific cruft from the important details.

When writing the .c file, #include "config.h" first, then the interface header (e.g., foo.h for foo.c - this ensures that the header has no missing dependencies), then all other headers.

I usually put them as close as practicable to the things that need them, whilst ensuring you don't set them incorrectly.

Related pieces of information should be kept close to make it easier to identify. A classic example is the ability for C to now allow variable definitions anywhere in the code rather than just at the top of a function:

void something (void) {
    // 600 lines of code here
    int x = fn(y);
    // more code here
}

is a lot better than:

void something (void) {
    int x;
    // 600 lines of code here
    x = fn(y);
    // more code here
}

since you don't have to go searching for the type of x in the latter case.

By way of example, if you need to compile a single source file multiple times with different values, you have to do it with the compiler:

gcc -Dmydefine=7 -o binary7 source.c
gcc -Dmydefine=9 -o binary9 source.c

However, if every compilation of that file will use 7, it can be moved closer to the place where it's used:

source.c:
    #include <stdio.h>

    #define mydefine 7
    #include "header_that_uses_mydefine.h"

    #define mydefine 7
    #include "another_header_that_uses_mydefine.h"

Note that I've done it twice so that it's more localised. This isn't a problem since, if you change only one, the compiler will tell you about it, but it ensures that you know those defines are set for the specific headers.

And, if you're certain that you will never include (for example) bitio.h without first setting BITCOUNT to 8, you can even go so far as to create a bitio8.h file containing nothing but:

#define BITCOUNT 8
#include "bitio.h"

and then just include bitio8.h in your source files.

Global, project-wide constants that are target specific are best put in CCFLAGS in your makefile. Constants you use all over the place can go in appropriate header files which are included by any file that uses them.

For example,

// bool.h - a boolean type for C
#ifndef __BOOL_H__
#define BOOL_H
typedef int bool_t
#define TRUE 1
#define FALSE 0
#endif

Then, in some other header,

`#include "bool.h"`
// blah

Using header files is what I recommend because it allows you to have a code base built by make files and other build systems as well as IDE projects such as Visual Studio. This gives you a single point of definition that can be accompanied by comments (I'm a fan of doxygen which allows you to generate macro documentation).

The other benefit with header files is that you can easily write unit tests to verify that only valid combinations of macros are defined.