On OSX, why does /usr/bin/cpp not support stringification of macro arguments while gcc -E and clang -E do?

Question

If I have the following code in foo.c

#define P(x) printf("%s\n", #x)

void main() {
  P(3 == 4);
}

Invoking gcc -E foo.c will output:

int main() {
  printf("%s\n", "3 == 4");
}

Notice that the # operator has stringified the literal for macro argument x. However, when I invoke /usr/bin/cpp, I get the following ... which is not expanded properly.

int main() {
  printf("%s\n", #3 == 4);
}

It's eerie how it goes from `4 == 3` to `#3 == 4`. Maybe you shouldn't download your compilers on April 1? — Kerrek SB, Feb 29 '12 at 23:14
3 == 4 is a typo on my part. I changed the code in between copies of the output. — Kelly Norton, Feb 29 '12 at 23:19
My /usr/bin/cpp is not llvm's preprocessor but gcc with the llvm backend. — Nikolai Ruhe, Feb 29 '12 at 23:31
Using Xcode (4.3) to show the preprocessed source file works for me. — Nikolai Ruhe, Feb 29 '12 at 23:31
Your code seems to work just fine for me when I compile it with `clang`. What happens if you use `clang -E` to run its own preprocessor? — Greg Hewgill, Feb 29 '12 at 23:32
@GregHewgill, clang -E works just fine. No idea why that would be inconsistent. — Kelly Norton, Feb 29 '12 at 23:35
I have a recently-built llvm-3.0 with clang, and there is no `cpp` binary produced in the build. I don't know what `cpp` you're running. — Greg Hewgill, Feb 29 '12 at 23:37
`cpp --version` gives "i686-apple-darwin11-llvm-gcc-4.2 (GCC) 4.2.1 (Based on Apple Inc. build 5658) (LLVM build 2336.1.00)" — Kelly Norton, Mar 01 '12 at 00:23
I think @NikolaiRuhe's comment suggests that my question should be reworded as LLVM is probably a red herring here. I'm actually asking why cpp and gcc -E differ in their handling of macros. — Kelly Norton, Mar 01 '12 at 00:28

score 11 · Answer 1 · answered Mar 01 '12 at 00:55

11

The cpp command is probably not behaving as a conformant C preprocessor but as a legacy pre-ANSI C preprocessor. My guess is that Apple made it work that way because Darwin is a BSD system and some broken legacy BSD software using the cpp command for non-C purposes (like macro processing for config files) would break in subtle ways if you dropped in a conformant C preprocessor in its place.

In any case, the cpp command should not be used since you never know what you'll get. c99 -E is the POSIX conformant way to invoke the C preprocessor, and $CC -E is probably the right way to do it in a Makefile.

answered Mar 01 '12 at 00:55

R.. GitHub STOP HELPING ICE

208,859
35
376
711

+1 - To add to the pre-ANSI `cpp` fun, here's a note by someone who found out that OS X `cpp` doesn't strip C++ style `//` comments: http://code.google.com/p/pycparser/wiki/CppOnMacOSX – Michael Burr Mar 01 '12 at 07:18
There are times on SO when I wish I could downvote downvoters. – Nikolai Ruhe Mar 01 '12 at 11:04
I'm guessing it was an Apple fanboy who was unhappy with my mildly harsh language about how `cpp` was intentionally broken for legacy compatibility... – R.. GitHub STOP HELPING ICE Mar 01 '12 at 14:12

Greg Hewgill · Accepted Answer · 2012-03-01T06:10:28.247

5

It looks like for some reason, the cpp on Lion (I have the same version as you) behaves as though the -traditional switch is enabled. I can reproduce the output you observed on other cpp binaries (Linux, FreeBSD), but only when using the -traditional switch.

After investigating this, it turns out that /usr/bin/cpp on Mac OS X is a script that starts out like this:

#!/bin/sh
#
# Transitional front end to CCCP to make it behave like (Reiser) CCP:
#       specifies -traditional
#       doesn't search gcc-include

There is apparently no way to undo -traditional with another option once it is specified by this script. One workaround is to use a specific installed version, such as cpp-4.2. Using cpp-4.2 on my system produces the desired expansion.

edited Mar 01 '12 at 06:10

answered Mar 01 '12 at 05:28

Greg Hewgill

951,095
183
1,149
1,285

CCCP? I knew the russians were somehow involved in this! – Nikolai Ruhe Mar 01 '12 at 11:09
Thanks @Greg, I should have occurred to me to see if `/usr/bin/cpp` was a script. – Kelly Norton Mar 01 '12 at 14:17

On OSX, why does /usr/bin/cpp not support stringification of macro arguments while gcc -E and clang -E do?

2 Answers2