56

Is is possible to print to stderr the value of a preprocessor variable in C? For example, what I have right now is:

#define PP_VAR (10)
#if (PP_VAR > 10)
    #warning PP_VAR is greater than 10
#endif

But what I'd like to do is:

#define PP_VAR (10)
#if (PP_VAR > 10)
    #warning PP_VAR=%PP_VAR%
#endif

Is something like this possible in C?

Brian Tompsett - 汤莱恩
  • 5,753
  • 72
  • 57
  • 129
apalopohapa
  • 4,983
  • 5
  • 27
  • 29

5 Answers5

66

You can print out the value of a preprocessor variable under visual studio. The following prints out the value of _MSC_VER:

#define STRING2(x) #x
#define STRING(x) STRING2(x)

#pragma message(STRING(_MSC_VER))

Not sure how standard this is though.

MattM
  • 919
  • 8
  • 9
22

This works with GCC 4.4.3:

#define STRING2(x) #x
#define STRING(x) STRING2(x)
#pragma message "LIBMEMCACHED_VERSION_HEX = " STRING(LIBMEMCACHED_VERSION_HEX)

yields:

src/_pylibmcmodule.c:1843: note: #pragma message: LIBMEMCACHED_VERSION_HEX = 0x01000017
Marc Abramowitz
  • 3,447
  • 3
  • 24
  • 30
5

Many C compilers support #warning (but it is not defined by the C standard).

However, GCC at least does not do pre-processing on the data that follows, which means it is hard to see the value of a variable.

#define PP_VAR 123
#warning "Value of PP_VAR = " PP_VAR
#warning "Value of PP_VAR = " #PP_VAR
#warning "Value of PP_VAR = " ##PP_VAR

GCC produces:

x.c:2:2: warning: #warning "Value of PP_VAR = " PP_VAR
x.c:3:2: warning: #warning "Value of PP_VAR = " #PP_VAR
x.c:4:2: warning: #warning "Value of PP_VAR = " ##PP_VAR
Jonathan Leffler
  • 730,956
  • 141
  • 904
  • 1,278
  • 17
    So when you say "it is hard to see the value of a variable," what you really mean is you CAN'T see it. – Nick Sep 29 '11 at 18:53
  • Roughly - yes; I have not worked out a way to see it, which is not the same as "there is no way to see it". – Jonathan Leffler Sep 29 '11 at 19:20
  • I ***think*** this is what I am trying to do.... I want to know what the runtime library is defining `SSIZE_MAX` to as a string (like `0`, `INT_MAX` or `LONG_MAX`), but the stringy is only returning `SSIZE_MAX` (the left hand side of the define). – jww Mar 28 '16 at 05:43
3

Use the preprocessor token-pasting operator: ##TOKEN_NAME

As previously noted, the preprocessor directives you are using are non-standard, so YMMV.

rtenhove
  • 175
  • 1
  • 6
1

Well, what you are doing is actually non-standard. Firstly, the "#warning" or "#warn" directive is not standard. Secondly, when using the preprocessor, the line must begin with the pound symbol, without any spaces:

#ifdef BLAH1
#    define BLAH2 // OK, because pound is at the very left.
#endif

#ifdef BLAH3
     #define BLAH4 // Works on many compilers, but is non-standard.
#endif

Since you are already using a non-standard extension, you will need to look up the documentation of the particular preprocessor/compiler that you are using to see what it says about "#warning".

Michael Aaron Safyan
  • 93,612
  • 16
  • 138
  • 200
  • 5
    Your second point is not correct - C89 lifted that restriction. The # must be the first symbol on the line, but it may be preceded by white space (but not by comments). – Jonathan Leffler Jul 30 '09 at 03:05
  • Thanks. I can't believe I'm still living in the dark ages. Can you point me to the relevant document for that? – Michael Aaron Safyan Jul 30 '09 at 03:09
  • Wow. I came later to the game than I thought - I never knew about that restriction at all. – Michael Kohne Jul 30 '09 at 03:15
  • @Jonathan: There is completely no issue with preceding any preprocessing directive with comment (at least c comment /*..*/) it will be replaced with single space in translation phase #3. Preprocessing directives are handled in phase #4 hence are not impacted by preceding c comment. – Artur Jun 23 '15 at 15:17
  • @Artur: You're right — but in the bad old days (really old days, pre-C89 standard days), comments were not allowed. My mix-up. (Mind you, there'd have to be a very, very good reason to include a comment before a preprocessor directive, and I can't think of any.) – Jonathan Leffler Jun 23 '15 at 15:22
  • @Jonathan: Sure - I do not see a reason to put a comment before preprocessing directive so what I wrote is just about doability and not any good/bad coding practise. – Artur Jun 23 '15 at 15:31