C preprocessor macro specialisation based on an argument

Question

Is it possible to have one macro expanded differently for one specific argument value and differently for all other arguments?

Say I define a current user:

#define CURRENT_USER john_smith

What I want to be able to do is to have a macro that will be expanded differently if user passed matches CURRENT_USER. Mind you that I don't know all possible user a priori. The most basic case:

#define IS_CURRENT_USER(user)                   \
    /* this is not valid preprocessor macro */  \
    #if user == CURRENT_USER                    \
        1                                       \
    #else                                       \
        0                                       \
    #endif

With macro like that every other macro relying on the username could be done following way:

#define SOME_USER_SPECIFIC_MACRO(user) SOME_USER_SPECIFIC_MACRO_SWITCH_1(IS_CURRENT_USER(user))

#define SOME_USER_SPECIFIC_MACRO_SWITCH_1(switch)   SOME_USER_SPECIFIC_MACRO_SWITCH_2(switch) // expand switch ...
#define SOME_USER_SPECIFIC_MACRO_SWITCH_2(switch)   SOME_USER_SPECIFIC_MACRO_##switch         // ... and select specific case

#define SOME_USER_SPECIFIC_MACRO_0  ... // not current user
#define SOME_USER_SPECIFIC_MACRO_1  ... // current user

Is this possible?

EDIT: Let me clarify. Say each programmer defines different CURRENT_USER in their config header. I want user specific macros to exand to something meaningful if and only if their user argument matches CURRENT_USER. As I would like those macros to contain _pragmas it can't be runtime check (as proposed in some anwsers below).

EDIT: Again, clarification. Say there's macro to disable optimisation of some sections of code:

#define TURN_OPTIMISATION_OFF __pragma optimize("", off)

Some programmers want to turn optimisation off for different sections of code but not all at one time. What I'd like is to have a macro:

#define TURN_OPTIMISATION_OFF(user) /* magic */

That will match user argument against CURRENT_USER macro, taken from per-programmer config file. If the user matches macro is expanded into pragma. If not, to nothing.

Where does the `user` argument come from? Is a preprocessed compler constant?? Why does the `_Pragma` requirement precludes "runtime" checking (which a good optimizing compiler would optimize at compile-time!). You really should tell more, showing more code, and explaining more. You also should look at the preprocessed output to understand the role of the preprocessor. — Basile Starynkevitch, Jul 24 '12 at 14:39
Did you consider improving your build machinery (e.g. your `Makefile`-s) so that the compiler is invoked with e.g. `-DCURRENT_USER_ID=$(shell id -u)`, assuming a Linux system with GNU `make`)? — Basile Starynkevitch, Jul 24 '12 at 14:56
I appreciate your suggestion, but where we define `CURRENT_USER` is irrevelant in this case. — gwiazdorrr, Jul 24 '12 at 14:57
You really should explain the overall goal of your potential pre-processor tricks. Is it developer-specific optimizations (which in my opinion is a mistake)? If it is, please state that and tell us your development system. — Basile Starynkevitch, Jul 24 '12 at 15:41
@BasileStarynkevitch: I tried to keep this question as abstract as possible. I welcome your input, but will abstain from discussion - I did not ask for general advice. I asked, very specifically, about C preprocessor mechanism. — gwiazdorrr, Jul 24 '12 at 16:41
Then just read the C specification, and study carefully the output of the preprocessor. Preprocessing is quite easy to grasp once you understood it is happenning "before" compilation, at the textual (i.e. lexical token) level. And please re-consider scripted generation of `#include`-ed header *C* files, it is a common practice! — Basile Starynkevitch, Jul 24 '12 at 16:43
Please read carefully http://en.wikipedia.org/wiki/C_preprocessor — Basile Starynkevitch, Jul 24 '12 at 17:03
@BasileStarynkevitch: I know how preprocessor works. From time to time one can find about a real pearl, even in the most familiar territory and that is the reason why I asked this question. I am still counting on some clever abuse of C preprocessor rules, maybe not doing exactly what I asked for, but at least something similar. — gwiazdorrr, Jul 24 '12 at 17:06
@BasileStarynkevitch: Wow, it *is* possible. Check my anwser. — gwiazdorrr, Jul 25 '12 at 14:55

score 27 · Answer 1 · edited May 18 '20 at 02:58

Well first, you can do pattern matching with the preprocessor using the ##. This is how an IIF macro could be defined:

#define IIF(cond) IIF_ ## cond
#define IIF_0(t, f) f
#define IIF_1(t, f) t

However there is one problem with this approach. A subtle side effect of the ## operator is that it inhibits expansion. Heres an example:

#define A() 1
//This correctly expands to true
IIF(1)(true, false) 
// This will however expand to IIF_A()(true, false)
// This is because A() doesn't expand to 1,
// because its inhibited by the ## operator
IIF(A())(true, false)

The way to work around this is to use another indirection. Since this is commonly done, we can write a macro called CAT that will concatenate without inhibition.

#define CAT(a, ...) PRIMITIVE_CAT(a, __VA_ARGS__)
#define PRIMITIVE_CAT(a, ...) a ## __VA_ARGS__

So now we can write the IIF macro:

#define IIF(c) PRIMITIVE_CAT(IIF_, c)
#define IIF_0(t, ...) __VA_ARGS__
#define IIF_1(t, ...) t

#define A() 1
//This correctly expands to true
IIF(1)(true, false) 
// And this will also now correctly expand to true
IIF(A())(true, false)

With pattern matching we can define other operations, such as COMPL which takes the complement:

// A complement operator
#define COMPL(b) PRIMITIVE_CAT(COMPL_, b)
#define COMPL_0 1
#define COMPL_1 0
// An and operator
#define BITAND(x) PRIMITIVE_CAT(BITAND_, x)
#define BITAND_0(y) 0
#define BITAND_1(y) y

Next, detection techniques can be used to detect if the parameter is a certain value or if it is parenthesis. It relies on variadic arguments expanding to different number of parameters. At the core of detection is a CHECK macro with a PROBE macro like this:

#define CHECK_N(x, n, ...) n
#define CHECK(...) CHECK_N(__VA_ARGS__, 0,)
#define PROBE(x) x, 1,

This is very simple. When the probe is given to the CHECK macro like this:

CHECK(PROBE(~)) // Expands to 1

But if we give it a single token:

CHECK(xxx) // Expands to 0

So with this, we can create some detection macros. For instance, if we want to detect for parenthesis:

#define IS_PAREN(x) CHECK(IS_PAREN_PROBE x)
#define IS_PAREN_PROBE(...) PROBE(~)
IS_PAREN(()) // Expands to 1
IS_PAREN(xxx) // Expands to 0

Next, we need to do a comparison of two tokens, we can rely on the fact that macros don't expand recursively. We force the macro to expand recursively inside of the other macro. If the two tokens are the same then the it will be expanding the macros recursively, which we will detect by trying detect if they expanded to parenthesis or not, here is the COMPARE macro:

#define COMPARE(a, b) PRIMITIVE_COMPARE(a, b)
#define PRIMITIVE_COMPARE(a, b) \
    IIF( \
        BITAND \
            (IS_PAREN(COMPARE_ ## a(()))) \
            (IS_PAREN(COMPARE_ ## b(()))) \
    )( \
        COMPL(IS_PAREN( \
            COMPARE_ ## a( \
                COMPARE_ ## b \
            )(()) \
        )), \
        0 \
    ) \

Each token you want to compare you would define like this:

// So you would define one for each user
#define COMPARE_john_smith(x) x
#define COMPARE_another_user_name(x) x

Now, I don't fully understand the final output you want generated, so say you have a macro for generating code for the current user and one for other users:

#define MACRO_CURRENT_USER(user) ...
#define MACRO_OTHER_USER(user) ...

Then you can write something like this:

// Detects if its the current user
#define IS_CURRENT_USER(user) COMPARE(user, CURRENT_USER)
// Your macro
#define MACRO(user) IIF(IS_CURRENT_USER(user))(MACRO_CURRENT_USER, MACRO_OTHER_USER)(user)

A cracking read. Does not do everything I asked for, but still, great one. MSVC compiler, however, does not seem to expand CHECK properly, always generating 0, no matter what you feed it with. — gwiazdorrr, Jul 25 '12 at 10:34
Also, isn't there an error in `IS_PAREN`? `IS_PAREN(xxx)` will just expand into `IS_PAREN_PROBE xxx`. Shouldn't it be defined as `CHECK( IS_PAREN_PROBE ## x)`? — gwiazdorrr, Jul 25 '12 at 11:01
It won't work on MSVC, it requires a C99 preprocessor. There are workarounds to make it work, though. — Paul Fultz II, Jul 25 '12 at 15:33
Ok, fixed `IS_PAREN`. It should be `CHECK( IS_PAREN_PROBE x)` because token pasting (`##`) parenthesis is not allowed in C99(although i think it will work more or less in MSVC) — Paul Fultz II, Jul 25 '12 at 15:42

gwiazdorrr · Accepted Answer · 2012-07-25T15:44:34.743

Tuns out it is possible. This anwser is based on Pauls macros, but much simpler and does not need definition for each user.

#define CAT(a, ...) PRIMITIVE_CAT(a, __VA_ARGS__)
#define PRIMITIVE_CAT(a, ...) a ## __VA_ARGS__

#define IIF(c) PRIMITIVE_CAT(IIF_, c)
#define IIF_0(t, ...) __VA_ARGS__
#define IIF_1(t, ...) t

#define PROBE(x) x, 1

Now, because of the MSVC bug I had to modify CHECK macro a bit.

#define MSVC_VA_ARGS_WORKAROUND(define, args) define args
#define CHECK(...) MSVC_VA_ARGS_WORKAROUND(CHECK_N, (__VA_ARGS__, 0))
#define CHECK_N(x, n, ...) n

Instead of defining CURRENT_USER I switched to following macros.

#define ENABLE_USER_gwiazdorrr () // gwiazdorrr is now enabled
#define ENABLE_USER_foo ()        // foo is also enabled
// #define ENABLE_USER_bar ()     // bar is NOT enabled

It actually gives more flexibility, because one can enable multiple user at the same time. The parenthesis is required. The macros below actually detect, whether ENABLE_USER_<user> is expanded into parenthesis or not.

#define USER_ENABLED_PROBE(user)            USER_ENABLED_PROBE_PROXY( ENABLE_USER_##user ) // concatenate prefix with user name
#define USER_ENABLED_PROBE_PROXY(...)       USER_ENABLED_PROBE_PRIMIVIE(__VA_ARGS__)       // expand arguments
#define USER_ENABLED_PROBE_PRIMIVIE(x)      USER_ENABLED_PROBE_COMBINE_##x                 // merge
#define USER_ENABLED_PROBE_COMBINE_(...)    PROBE(~)                                       // if merge successful, expand to probe

USER_ENABLED_PROBE(gwiazdorrr) // expands to ~, 1
USER_ENABLED_PROBE(bar)        // expands to USER_ENABLED_PROBE_COMBINE_bar

From now it is a childs play:

#define IS_USER_ENABLED(user) CHECK(USER_ENABLED_PROBE(user))

IS_USER_ENABLED(gwiazdorrr)   // expands to 1
IS_USER_ENABLED(bar)          // expands to 0

Having this macro and IIF (thanks Paul!) I decided to implement the optimisation macro mentioned in the original question:

#define TURN_OPTIMISATION_OFF(user) IIF( IS_USER_ENABLED(user) ) \
    (\
        __pragma optimize("", off),\
        /* nothing */ \
    )

TURN_OPTIMISATION_OFF(gwiazdorrr) // expands into __pragma optimize("", off)
TURN_OPTIMISATION_OFF(foo)        // expands into __pragma optimize("", off)
TURN_OPTIMISATION_OFF(bar)        // nothing emitted

Thanks for input!

EDIT: here's the GCC version: http://ideone.com/129eo

score 2 · Answer 3 · edited Jun 24 '19 at 08:53

If the argument to the macro is always very constant (even literally and lexically) you could play tricks with concatenation, something like

#define SOME_MACRO(T) SOME_MACRO_FOR_##T
#define SOME_MACRO_FOR_0 somethinghere()
#define SOME_MACRO_FOR_1 somethingelse()

Otherwise, you could have

#define CURRENT_USER ((user == THE_USER)?(something()):(somethingelse()))

Or use a static inline tiny function:

static inline int current_user(int user)
{
   return (user==THE_USER)?(something()):(somethingelse());
}

(Notice that if user is a constant, perhaps after some previous compiler optimization, the compiler would optimize that to something simpler, and the compiled binary won't test user at runtime. See also __builtin_constant_p if compiling with gcc).

But I believe your preprocessor tricks might make your code less readable. Think twice when making them.

And you didn't tell us what is your exact macro usage. Do you use it as an lvalue?

As you say, the preprocessor cannot expand to preprocessing directive, so your example :

#define IS_CURRENT_USER(user)                   \
  /* this is not valid preprocessor macro */  \
  #if user == CURRENT_USER                    \
      1                                       \
  #else                                       \
      0                                       \
  #endif

is (as you say) incorrect.

You are only allowed to do things like :

 #if user == CURRENT_USER
 #define IS_CURRENT_USER(U) 1
 #else
 #define IS_CURRENT_USER(u) 0
 #endif

I knowingly am using u not user as the formal argument to your macro IS_CURRENT_USER for readability (that formal is not expanded, only its occurrences in the macro are).

Do you realize that preprocessing happens "before" compilation? Did you run e.g. gcc -C -E to get the preprocessed ouput? It should be instructive!

Read more about the C preprocessor

BTW, did you consider generating some C code (perhaps to be #include-d somewhere) with a script (or your own generator, or autotools, or a generic preprocessor like autogen or m4)? You could generate (from e.g. a user base such as /etc/passwd on Linux, or NIS/YP, LDAP or with getpwent(3) ...) an #include-d myoptim.h with things like

#if CURRENT_USER_ID==1234
#define OPTIMIZATION_FOR_PAUL _pragma(GCC(optimize,"-O1"))
#else
#define OPTIMIZATION_FOR_PAUL /*nothing*/
#endif
#if CURRENT_USER_ID==3456
#define OPTIMIZATION_FOR_ALICE _pragma(GCC(optimize,"-O1"))
#else
#define OPTIMIZATION_FOR_ALICE /*nothing*/
#endif

and ask Paul (assuming his uid is 1234) to prefix his functions with OPTIMIZATION_FOR_PAUL and put CFLAGS=-DCURRENT_USER_ID=$(shell id -u) in your Makefile; I find that ugly (and it does not address the fact that optimization might alter globally behavior of ill-coded programs).

You could customize GCC with e.g. a MELT extension providing a custom pragma or builtin for your needs, but I find that weird in your particular case.

NB. Historically, cpp was designed to be a quick textual processor, not Turing-complete. In the old days (1980-s Unix) it ran as a separate process, with the real compilation done by cc1, and the cc compiler was just a shell script driving them (with as and ld). Today, gcc is a small driver program, but cc1 incorporates the pre-processor for performance reasons. Still, the C standard is specified so that the pre-processing can be a separate program from the compiler proper.

As for concatenation, I covered it in the original question. I also clarified on how I plan to use those macros. And I don't think that code generation is valid solution here, as I need to change how macros are expanded in existing code, depending on current user. — gwiazdorrr, Jul 24 '12 at 15:02
You certainly can generate an included *C* file with a lot of preprocessor conditionals like `#if` ; this is standard practice with GNU autotools. — Basile Starynkevitch, Jul 24 '12 at 15:13
As I stated in the question, I do not know all the possible users. So unfortunatelly, that won't do. — gwiazdorrr, Jul 24 '12 at 15:28
On Unix systems, the set of possible users is known (e.g. from `/etc/passwd`, NIS/YP, LDAP, or the `getpwent(3)` library function). So you can code a generator of `myoptim.h` like I suggest. I can't imagine a system not knowing its set of users... — Basile Starynkevitch, Jul 24 '12 at 15:32
I know nothing about Microsoft Windows, but a quick search tells that with "ADSI Scripting" you could programmatically iterate on the user base. — Basile Starynkevitch, Jul 24 '12 at 16:08
Those are great suggestions and you definitely need more upvotes than mine. Still I won't accept it, since the question is about specialising macro for one argument value and generalising it for others. — gwiazdorrr, Jul 24 '12 at 16:49
You simply cannot do what you ask. The C standard defines quite well what the preprocessor should do. — Basile Starynkevitch, Jul 24 '12 at 16:50
Actually the preprocessor can act very close like a turing machine. See http://stackoverflow.com/a/10526117/375343 — Paul Fultz II, Jul 25 '12 at 16:05

Luchian Grigore · Answer 4 · 2012-07-24T15:09:55.903

2

Preprocessing takes place before compilation.

If user is known to the preprocessor, then yes:

#define user 4
#define CURRENT_USER 4
#define IS_CURRENT_USER 1

#if user == CURRENT_USER
#define IS_CURRENT_USER(user) 1
#else
#define IS_CURRENT_USER(user) 0
#endif

But this is utterly useless and I doubt it's what you actually have.

Otherwise, no. Don't abuse mecros and the preprocessor.

After your edit:

No, what you want is definitely not possible (turn off optimizations depending on user).

edited Jul 24 '12 at 15:09

answered Jul 24 '12 at 14:00

Luchian Grigore

253,575
64
457
625

The user is specified by `CURRENT_USER`, what's the point of having another `user` definied? – gwiazdorrr Jul 24 '12 at 14:10
@gwiazdorrr there is none. There's no point in any of this. But this is the only situation where what you want actually works. – Luchian Grigore Jul 24 '12 at 14:13
gwiazdorrr could generate a header file, see my (edited) answer. – Basile Starynkevitch Jul 24 '12 at 15:50
@LuchianGrigore: turns out it *is* possible. Check out my anwser. – gwiazdorrr Jul 25 '12 at 15:02
@gwiazdorrr doesn't that turn user in a pre-processing concept? – Luchian Grigore Jul 25 '12 at 15:08
@gwiazdorrr so then my answer still applies, I just had the conversion simplified. – Luchian Grigore Jul 25 '12 at 15:11
@gwiazdorrr will it still work if a user is read from the input? i.e. not known beforehand? – Luchian Grigore Jul 25 '12 at 15:13
@LuchianGrigore: *No*. Honestly, your macros do nothing. There's no expansion based on the parameter *you supply to IS_CURRENT_USER*. Please, read my question and anwser again. Anwsering to your edit: you miss the entire point of this question. – gwiazdorrr Jul 25 '12 at 15:15
@gwiazdorrr can you provide an example on ideone? – Luchian Grigore Jul 25 '12 at 15:22
@LuchianGrigore: I had to modify it a bit to fit GCC, but here it is: http://ideone.com/129eo. Keep in mind that `USER_ENABLE_` should be kept in per user (per programmer) config file. – gwiazdorrr Jul 25 '12 at 15:35
@gwiazdorrr so for user foo, optimizations are off? And for bar, not? – Luchian Grigore Jul 25 '12 at 15:38
@LuchianGrigore: yes. Keep in mind that this mechanizm can be utilised for other user-specific compile-time code blocks, since it works on preprocessor level. As I mention couple times, I am not here to solve a problem, I am here to use C preprocessor in this specific way. – gwiazdorrr Jul 25 '12 at 15:43
@gwiazdorrr I agree, but I'm saying it's largely the same principle. You still need to define the users you want in the preprocessor - `#define ENABLE_USER_gwiazdorrr ()` – Luchian Grigore Jul 25 '12 at 15:44
@LuchianGrigore Yes, but you can do that in per-user file. Rest of the codebase is not affected. With one definition you change how all per-user macros are expanded, which is awesome IMO. – gwiazdorrr Jul 25 '12 at 16:06
@gwiazdorrr I agree it's much cleaner, but the principle remains. Pre-processing happens before runtime, you can't control compile-paths with user input. I'm glad you solved your problem, you can accept your own answer to help others facing the same issue. – Luchian Grigore Jul 25 '12 at 16:56

score 2 · Answer 5 · answered Apr 26 '14 at 23:22

The code below is not sensitive to the MSVC bug. The ... arguments are not separated.

#define IF_USER_ENABLED(x,...) IF_USER_ARGS_GT2 (ENABLE_USER_ ## x,__VA_ARGS__) 
#define IF_USER_ARGS_GT2(x,...) ARGS_ARG2 (x,GT4,3,,__VA_ARGS__)
#define ARGS_ARG2(x,y,z,...) ARGS_ ## z (x,y,z,__VA_ARGS__)
#define ARGS_3(x,y,z,w,...) w
#define ARGS_GT4(x,y,z,w,v,...) __VA_ARGS__

#define IF_USER_DISABLED(x,...) IF_NOT_USER_ARGS_GT2 (ENABLE_USER_ ## x,__VA_ARGS__) 
#define IF_NOT_USER_ARGS_GT2(x,...) ARGS_ARG2 (x,4,GT3,,__VA_ARGS__)
#define ARGS_4(x,y,z,w,v,...) v
#define ARGS_GT3(x,y,z,w,...) __VA_ARGS__

#define ENABLE_USER_foo ,
//#define ENABLE_USER_bar ,

Defining a macro as a comma ??? so you can pass a comma as a macro argument ??? so you can shift the argument positions ??? How ineffably convoluted! — Jesse Chisholm, May 20 '14 at 14:35

score 0 · Answer 6 · edited Sep 16 '19 at 05:33

0

Why didn't you use simple if statement? #if can't be used in a macro.

Here is an example:

// Return 1 if `user' is the current user, 0 else.
#define IS_CURRENT_USER(user) ((user) == CURRENT_USER)

Or if you set your USER during the compilation, you can reduce the number of conditional branches.

#if USER == CURRENT_USER
# define IS_CURRENT_USER (1)
#else
# define IS_CURRENT_USER (0)
#endif

edited Sep 16 '19 at 05:33

Jonathan Leffler

730,956
141
904
1,278

answered Jul 24 '12 at 13:51

md5

23,373
3
44
93

I stated that I'd like the macro to be *expanded* differently. Also, I don't want different expansion for specific user, I want different expansion for *current*, unspecified user. – gwiazdorrr Jul 24 '12 at 14:11
1

What is `current` ? A preprocessor constant, a global variable, a local one? You are confusing and possibly confused. – Basile Starynkevitch Jul 24 '12 at 14:23

score 0 · Answer 7 · answered Jul 24 '12 at 14:04

0

What's wrong with something like that?

#if CURRENT_USER == john_smith
    #define SOME_USER_SPECIFIC_MACRO_SWITCH  WHATEVER ## CURRENT_USER
    #define SOME_USER_SPECIFIC_MACRO_1  ... 
#else
    #define SOME_USER_SPECIFIC_MACRO_0  ... 
    #define SOME_USER_SPECIFIC_MACRO_SWITCH  WHATEVER ## Somethingelse
#endif// not current user

answered Jul 24 '12 at 14:04

Patrick Schlüter

11,394
1
43
48

1

I don't want to expand something differently for john_smith; it is a specific user. I want macros to be expanded differently for a user specified by CURRENT_USER. See my clarifications in the question. – gwiazdorrr Jul 24 '12 at 15:04

C preprocessor macro specialisation based on an argument

7 Answers7

Linked