mikeash.com pyblog/friday-qa-2009-08-21-writing-vararg-macros-and-functions.html comments

mikeash - 2009-10-28 15:04:49

Wed, 28 Oct 2009 15:04:49 GMT

Definitely not missing a comma. Imagine this usage of the macro:

DEBUG_LOG("the answer is %d", fortyTwo);

With the comma, the line would expand to:

fprintf(stderr, "Debug log:", "the answer is %d", fortyTwo);

With the result that it will print only the text, "Debug log:", and nothing else.

Without the comma, it expands to this:

fprintf(stderr, "Debug log:" "the answer is %d", fortyTwo);

The adjacent string literals get concatenated, and so it prints, "Debug log:the answer is 42".

It ought to have a space after the colon, though....

Jeanne d'Arc - 2009-10-28 10:41:28

Wed, 28 Oct 2009 10:41:28 GMT

There's probably a missing ',' here:

fprintf(stderr, "Debug log:" __VA_ARGS__); \

mikeash - 2009-08-25 14:07:38

Tue, 25 Aug 2009 14:07:38 GMT

It's likely that clang supports such devices as well. Their stated goal is to support nearly all gcc language extensions so that clang is able to build nearly all existing gcc-targeted code.

Your ARRAY macro ought to work for empty arrays as well, but you have to pass an explicit nil parameter instead of just leaving the list empty. If you really wanted to you could pair it with a custom vararg function/method that allowed an empty parameter list in the macro.

Vasi - 2009-08-25 07:31:09

Tue, 25 Aug 2009 07:31:09 GMT

A drawback of using do/while is that your macro can't return a value. (I also find do/while in macros aesthetically unpleasant, but that's just me.) An alternative is to use GCC's multi-statement expressions: http://gcc.gnu.org/onlinedocs/gcc-4.4.1/gcc/Statement-Exprs.html#Statement-Exprs . This lets you do things like:

#define ARRAY_DEBUG(...) ({
    NSArray *_a = [NSArray arrayWithObjects: __VA_ARGS__];
    if (gDebug)
        dumpArray(_a);
    _a;
})

...

NSArray *myArray = ARRAY_DEBUG(@"foo", @"bar", nil);

The downside is of course that this is non-portable. I have no idea whether or not clang supports this extension.

On a different note, one very common use for vararg macros is to abbreviate nil-terminated vararg functions. Eg:

#define ARRAY(...) [NSArray arrayWithObjects: __VA_ARGS__, nil]

This has the drawback of not working for empty arrays, but there are easier ways to create those. Jens Alfke's utilities may be better https://bitbucket.org/snej/myutilities/src/tip/CollectionUtils.h

mikeash - 2009-08-24 15:41:27

Mon, 24 Aug 2009 15:41:27 GMT

Heh. Whoops. Thanks Peter! I've fixed all three now.

Peter N Lewis - 2009-08-24 14:01:38

Mon, 24 Aug 2009 14:01:38 GMT

Regardless of whether the DEBUG_LOG uses { } or do while, it really should have an equal number of opening and closing currly brackets.

It is also definitely worth mentioning the NS_REQUIRES_NIL_TERMINATION macro!

gabe - 2009-08-23 09:24:24

Sun, 23 Aug 2009 09:24:24 GMT

Some more detail on multi statement macros from comp.lang.c faq, http://c-faq.com/cpp/multistmt.html

mikeash - 2009-08-22 23:06:44

Sat, 22 Aug 2009 23:06:44 GMT

Regardless of the actual calling conventions, you should never write code that calls functions without prototypes. Aside from being non-conforming code even if it does happen to work on your particular platform, it's also all too easy to screw up your types. For example, it is impossible to correctly call a function which takes a float parameter in this way, because a float passed to a prototype-less function will always be promoted to double. It's also easy to accidentally pass 0 instead of 0.0, which would normally cause a harmless implicit conversion but in the absence of a prototype will screw you over hard.

Jean-Daniel Dupas - 2009-08-22 22:31:59

Sat, 22 Aug 2009 22:31:59 GMT

In particular, on platforms that use registers to pass arguments they tend to shove all of the args into GPRs even though the standard calling convention might have you place singles and doubles in FPRs

That not quite true. See for example on PPC:

printf("%f", 10.0);

Generate this assembly:
=> fmr f1,f0
bl _fprintf$LDBL128

And it uses mmx register on x86_64.

So you can see that even on arch that uses register to pass argument, floating point register are use to pass floating point values.

Louis Gerbarg - 2009-08-22 19:41:38

Sat, 22 Aug 2009 19:41:38 GMT

It might be worth mentioning that on a number of architectures variadic functions have substantially different calling conventions that non-variadic functions. In particular, on platforms that use registers to pass arguments they tend to shove all of the args into GPRs even though the standard calling convention might have you place singles and doubles in FPRs, since the compiler doesn't have any type info for the va_args.

This manifests itself in several ways. The first is slightly less efficient code (copying stuff back and forth from fprs to gprs, or extra copies to the stack), the second is that if you ignore missing prototype warnings (everyone compiles with -Wall=error, right) you may get code that links correctly but crashes because the calling function doesn't put things where the called function expects them.

Jonas Witt - 2009-08-22 01:30:50

Sat, 22 Aug 2009 01:30:50 GMT

Ok, so you were referring to the semicolon which is required after the do/while but won't work after the { } block. Thanks for the explanation.

mikeash - 2009-08-22 01:07:54

Sat, 22 Aug 2009 01:07:54 GMT

No, curly braces do not achieve the same effect. Go look at my example if/else code and consider what happens if you use your style in there. It will not compile.

Cedric Luthi - 2009-08-22 00:42:55

Sat, 22 Aug 2009 00:42:55 GMT

A nice complement to this article: Variable argument lists in Cocoa
http://cocoawithlove.com/2009/05/variable-argument-lists-in-cocoa.html

Worth a read.

Jonas Witt - 2009-08-22 00:35:36

Sat, 22 Aug 2009 00:35:36 GMT

You say that using do/while(0) is a great way to put multiple statements in a macro (if you don't want it to fail in places where a single statement is expected), but the same can be achieved simply by using a pair of curly braces (which you use for while anyway since while expects a single statement/block) to create a new scope/block:

#define FOO { method1(); method2(); }

IMO this is idential to the while construct in every aspect (variable scope, ...).

mikeash - 2009-08-22 00:30:46

Sat, 22 Aug 2009 00:30:46 GMT

I actually discuss the 0 problem, in a slightly different context, in the Beware of NULL section of Format Strings Tips and Tricks from a month ago:

http://www.mikeash.com/?page=pyblog/friday-qa-2009-07-17-format-strings-tips-and-tricks.html

Chris - 2009-08-22 00:10:24

Sat, 22 Aug 2009 00:10:24 GMT

Another omission is the "gotcha" related to (IIRC) argument promotion and callers passing an integer 0 instead of a zero *pointer* to terminate the argument list.

This causes problems (again, IIRC) on 64-bit systems.

Jordy/Jediknil - 2009-08-21 23:59:28

Fri, 21 Aug 2009 23:59:28 GMT

Very convenient, but you left out the most confusing one: vararg methods!

Like vararg functions, vararg methods require at least one fixed parameter. The va_list/va_start/va_arg API is the same. And they are declared like this:

- (NSString *)stringByAppendingStrings:(NSString *)first, ...;

And the restriction of one fixed argument is a lot more arbitrary here, because, as we well know, an Objective-C method is passed two hidden arguments (self and _cmd). In theory I would expect va_start(_cmd) to work, but I wouldn't use it in practice, especially given potential compiler differences in this field!

Finally, there's a nice macro called NS_REQUIRES_NIL_TERMINATION that expands to a GCC __attribute__ ((sentinel)), which will warn when any invocations of the function aren't nil-terminated (if you have -Wformat turned on). This works for both functions and methods.