Next: , Previous: , Up: Compilers and Preprocessors   [Contents][Index]

5.10.3 C Compiler Characteristics

The following macros provide ways to find and exercise a C Compiler. There are a few constructs that ought to be avoided, but do not deserve being checked for, since they can easily be worked around.

Don’t use lines containing solitary backslashes

They tickle a bug in the HP-UX C compiler (checked on HP-UX 10.20, 11.00, and 11i). When given the following source: 

#ifdef __STDC__
/\
* A comment with backslash-newlines in it.  %{ %} *\
\
/
char str[] = "\\
" A string with backslash-newlines in it %{ %} \\
"";
char apostrophe = '\\
\
'\
';
#endif

the compiler incorrectly fails with the diagnostics “Non-terminating comment at end of file” and “Missing ‘#endif’ at end of file.” Removing the lines with solitary backslashes solves the problem.

Don’t compile several files at once if output matters to you

Some compilers, such as HP’s, report names of files being compiled when given more than one file operand. For instance: 

$ cc a.c b.c
a.c:
b.c:

This can cause problems if you observe the output of the compiler to detect failures. Invoking ‘cc -c a.c && cc -c b.c && cc -o c a.o b.o’ solves the issue.

Don’t rely on #error failing

The IRIX C compiler does not fail when #error is preprocessed; it simply emits a diagnostic and continues, exiting successfully. So, instead of an error directive like #error "Unsupported word size" it is more portable to use an invalid directive like #Unsupported word size in Autoconf tests. In ordinary source code, #error is OK, since installers with inadequate compilers like IRIX can simply examine these compilers’ diagnostic output.

Don’t rely on correct #line support

On Solaris, c89 (at least Sun C 5.3 through 5.8) diagnoses #line directives whose line numbers are greater than 32767. Nothing in Posix makes this invalid. That is why Autoconf stopped issuing #line directives.

Macro: AC_PROG_CC ([compiler-search-list])

Determine a C compiler to use.

If the environment variable CC is set, its value will be taken as the name of the C compiler to use. Otherwise, search for a C compiler under a series of likely names, trying gcc and cc first. Regardless, the output variable CC is set to the chosen compiler.

If the optional first argument to the macro is used, it must be a whitespace-separated list of potential names for a C compiler, which overrides the built-in list.

If no C compiler can be found, configure will error out.

If the selected C compiler is found to be GNU C (regardless of its name), the shell variable GCC will be set to ‘yes’. If the shell variable CFLAGS was not already set, it is set to -g -O2 for the GNU C compiler (-O2 on systems where GCC does not accept -g), or -g for other compilers. CFLAGS is then made an output variable. You can override the default for CFLAGS by inserting a shell default assignment between AC_INIT and AC_PROG_CC: 

: ${CFLAGS="options"}

where options are the appropriate set of options to use by default. (It is important to use this construct rather than a normal assignment, so that CFLAGS can still be overridden by the person building the package. See Preset Output Variables.)

If necessary, options are added to CC to enable support for ISO Standard C features with extensions, preferring the newest edition of the C standard that is supported. Currently the newest edition Autoconf knows how to detect support for is ISO C 2011. After calling this macro you can check whether the C compiler has been set to accept standard C by inspecting the shell variable ac_prog_cc_stdc. Its value will be ‘c11’, ‘c99’, or ‘c89’, respectively, if the C compiler has been set to use the 2011, 1999, or 1990 edition of the C standard, and ‘no’ if the compiler does not support compiling standard C at all.

The tests for standard conformance are not comprehensive. They test the values of __STDC__ and __STDC_VERSION__, and a representative sample of the language features added in each version of the C standard. They do not test the C standard library, because the C compiler might be generating code for a “freestanding environment” (in which most of the standard library is optional). If you need to know whether a particular C standard header exists, use AC_CHECK_HEADER.

None of the options that may be added to CC by this macro enable strict conformance to the C standard. In particular, system-specific extensions are not disabled. (For example, for GNU C, the -std=gnunn options may be used, but not the -std=cnn options.)

Many Autoconf macros use a compiler, and thus call ‘AC_REQUIRE([AC_PROG_CC])’ to ensure that the compiler has been determined before the body of the outermost AC_DEFUN macro. Although AC_PROG_CC is safe to directly expand multiple times, it performs certain checks (such as the proper value of EXEEXT) only on the first invocation. Therefore, care must be used when invoking this macro from within another macro rather than at the top level (see Expanded Before Required).

Macro: AC_PROG_CC_C_O

If the C compiler does not accept the -c and -o options simultaneously, define NO_MINUS_C_MINUS_O. This macro actually tests both the compiler found by AC_PROG_CC, and, if different, the first cc in the path. The test fails if one fails. This macro was created for GNU Make to choose the default C compilation rule.

For the compiler compiler, this macro caches its result in the ac_cv_prog_cc_compiler_c_o variable.

Macro: AC_PROG_CPP

Set output variable CPP to a command that runs the C preprocessor. If ‘$CC -E’ doesn’t work, tries cpp and /lib/cpp, in that order.

It is only portable to run CPP on files with a .c extension.

Some preprocessors don’t indicate missing include files by the error status. For such preprocessors an internal variable is set that causes other macros to check the standard error from the preprocessor and consider the test failed if any warnings have been reported. For most preprocessors, though, warnings do not cause include-file tests to fail unless AC_PROG_CPP_WERROR is also specified.

Macro: AC_PROG_CPP_WERROR

This acts like AC_PROG_CPP, except it treats warnings from the preprocessor as errors even if the preprocessor exit status indicates success. This is useful for avoiding headers that generate mandatory warnings, such as deprecation notices.

The following macros check for C compiler or machine architecture features. To check for characteristics not listed here, use AC_COMPILE_IFELSE (see Running the Compiler) or AC_RUN_IFELSE (see Checking Runtime Behavior).

Macro: AC_C_BACKSLASH_A

Define ‘HAVE_C_BACKSLASH_A’ to 1 if the C compiler understands ‘\a’.

This macro is obsolescent, as current C compilers understand ‘\a’. New programs need not use this macro.

Macro: AC_C_BIGENDIAN ([action-if-true], [action-if-false], [action-if-unknown], [action-if-universal])

If words are stored with the most significant byte first (like Motorola and SPARC CPUs), execute action-if-true. If words are stored with the least significant byte first (like Intel and VAX CPUs), execute action-if-false.

This macro runs a test-case if endianness cannot be determined from the system header files. When cross-compiling, the test-case is not run but grep’ed for some magic values. action-if-unknown is executed if the latter case fails to determine the byte sex of the host system.

In some cases a single run of a compiler can generate code for multiple architectures. This can happen, for example, when generating Mac OS X universal binary files, which work on both PowerPC and Intel architectures. In this case, the different variants might be for architectures with differing endianness. If configure detects this, it executes action-if-universal instead of action-if-unknown.

The default for action-if-true is to define ‘WORDS_BIGENDIAN’. The default for action-if-false is to do nothing. The default for action-if-unknown is to abort configure and tell the installer how to bypass this test. And finally, the default for action-if-universal is to ensure that ‘WORDS_BIGENDIAN’ is defined if and only if a universal build is detected and the current code is big-endian; this default works only if autoheader is used (see Using autoheader to Create config.h.in).

If you use this macro without specifying action-if-universal, you should also use AC_CONFIG_HEADERS; otherwise ‘WORDS_BIGENDIAN’ may be set incorrectly for Mac OS X universal binary files.

Macro: AC_C_CONST

If the C compiler does not fully support the const keyword, define const to be empty. Some C compilers that do not define __STDC__ do support const; some compilers that define __STDC__ do not completely support const. Programs can simply use const as if every C compiler supported it; for those that don’t, the makefile or configuration header file defines it as empty.

Occasionally installers use a C++ compiler to compile C code, typically because they lack a C compiler. This causes problems with const, because C and C++ treat const differently. For example: 

const int foo;

is valid in C but not in C++. These differences unfortunately cannot be papered over by defining const to be empty.

If autoconf detects this situation, it leaves const alone, as this generally yields better results in practice. However, using a C++ compiler to compile C code is not recommended or supported, and installers who run into trouble in this area should get a C compiler like GCC to compile their C code.

This macro caches its result in the ac_cv_c_const variable.

This macro is obsolescent, as current C compilers support const. New programs need not use this macro.

Macro: AC_C__GENERIC

If the C compiler supports C11-style generic selection using the _Generic keyword, define HAVE_C__GENERIC.

Macro: AC_C_RESTRICT

If the C compiler recognizes a variant spelling for the restrict keyword (__restrict, __restrict__, or _Restrict), then define restrict to that; this is more likely to do the right thing with compilers that support language variants where plain restrict is not a keyword. Otherwise, if the C compiler recognizes the restrict keyword, don’t do anything. Otherwise, define restrict to be empty. Thus, programs may simply use restrict as if every C compiler supported it; for those that do not, the makefile or configuration header defines it away.

Although support in C++ for the restrict keyword is not required, several C++ compilers do accept the keyword. This macro works for them, too.

This macro caches ‘no’ in the ac_cv_c_restrict variable if restrict is not supported, and a supported spelling otherwise.

Macro: AC_C_VOLATILE

If the C compiler does not understand the keyword volatile, define volatile to be empty. Programs can simply use volatile as if every C compiler supported it; for those that do not, the makefile or configuration header defines it as empty.

If the correctness of your program depends on the semantics of volatile, simply defining it to be empty does, in a sense, break your code. However, given that the compiler does not support volatile, you are at its mercy anyway. At least your program compiles, when it wouldn’t before. See Volatile Objects, for more about volatile.

In general, the volatile keyword is a standard C feature, so you might expect that volatile is available only when __STDC__ is defined. However, Ultrix 4.3’s native compiler does support volatile, but does not define __STDC__.

This macro is obsolescent, as current C compilers support volatile. New programs need not use this macro.

Macro: AC_C_INLINE

If the C compiler supports the keyword inline, do nothing. Otherwise define inline to __inline__ or __inline if it accepts one of those, otherwise define inline to be empty.

Macro: AC_C_CHAR_UNSIGNED

If the C type char is unsigned, define __CHAR_UNSIGNED__, unless the C compiler predefines it.

These days, using this macro is not necessary. The same information can be determined by this portable alternative, thus avoiding the use of preprocessor macros in the namespace reserved for the implementation. 

#include <limits.h>
#if CHAR_MIN == 0
# define CHAR_UNSIGNED 1
#endif
Macro: AC_C_STRINGIZE

If the C preprocessor supports the stringizing operator, define HAVE_STRINGIZE. The stringizing operator is ‘#’ and is found in macros such as this: 

#define x(y) #y

This macro is obsolescent, as current C compilers support the stringizing operator. New programs need not use this macro.

Macro: AC_C_FLEXIBLE_ARRAY_MEMBER

If the C compiler supports flexible array members, define FLEXIBLE_ARRAY_MEMBER to nothing; otherwise define it to 1. That way, a declaration like this: 

struct s
  {
    size_t n_vals;
    double val[FLEXIBLE_ARRAY_MEMBER];
  };

will let applications use the “struct hack” even with compilers that do not support flexible array members. To allocate and use such an object, you can use code like this: 

size_t i;
size_t n = compute_value_count ();
struct s *p =
   malloc (offsetof (struct s, val)
           + n * sizeof (double));
p->n_vals = n;
for (i = 0; i < n; i++)
  p->val[i] = compute_value (i);
Macro: AC_C_VARARRAYS

If the C compiler does not support variable-length arrays, define the macro __STDC_NO_VLA__ to be 1 if it is not already defined. A variable-length array is an array of automatic storage duration whose length is determined at run time, when the array is declared. For backward compatibility this macro also defines HAVE_C_VARARRAYS if the C compiler supports variable-length arrays, but this usage is obsolescent and new programs should use __STDC_NO_VLA__.

Macro: AC_C_TYPEOF

If the C compiler supports GNU C’s typeof syntax either directly or through a different spelling of the keyword (e.g., __typeof__), define HAVE_TYPEOF. If the support is available only through a different spelling, define typeof to that spelling.

Macro: AC_C_PROTOTYPES

If function prototypes are understood by the compiler (as determined by AC_PROG_CC), define PROTOTYPES and __PROTOTYPES. Defining __PROTOTYPES is for the benefit of header files that cannot use macros that infringe on user name space.

This macro is obsolescent, as current C compilers support prototypes. New programs need not use this macro.

Macro: AC_PROG_GCC_TRADITIONAL

Add -traditional to output variable CC if using a GNU C compiler and ioctl does not work properly without -traditional. That usually happens when the fixed header files have not been installed on an old system.

This macro is obsolescent, since current versions of the GNU C compiler fix the header files automatically when installed.

Next: C++ Compiler Characteristics, Previous: Generic Compiler Characteristics, Up: Compilers and Preprocessors   [Contents][Index]