mikeash.com pyblog/friday-qa-2009-07-17-format-strings-tips-and-tricks.html comments

Peter N Lewis - 2009-07-27 17:21:22

Mon, 27 Jul 2009 17:21:22 GMT

blockquote>For example, here is a convenient way to turn a FourCharCode into an NSString:
<pre> uint32_t valSwapped = CFSwapInt32HostToBig(fcc); // FCCs are stored backwards on Intel
NSString *str = [NSString stringWithFormat:@"%.4s", &valSwapped;];
</pre>

While %.Ns is a clever trick, this wont actually work in general because OSTypes are defined to be in MacRoman the character set where stringWithFormat uses the system encoding which may be different.

Instead you need to use something like:

NSData* data = [NSData dataWithBytes:&valSwapped length:sizeof(valSwapped)];
return [[[NSString alloc]initWithData:data encoding:NSMacOSRomanStringEncoding] autorelease];

Adam Rosenfield - 2009-07-25 23:33:47

Sat, 25 Jul 2009 23:33:47 GMT

The exact output of the %p specifier is implementation-defined; some implementations prepend a 0x to the output, some don't, some use uppercase, and some use lowercase. If you want a guaranteed output format, you should do something like:

printf("0x%08x\n", (uint32_t)ptr);

And use llx instead of x for 64-bit systems. Whenever you're printing out pointer values, 99.99% of the time you're debugging something, so you know the size of pointers on your platform. Hence, it's ok to be lazy and ditch the pointer-to-integer cast entirely.

I also strongly recommend always compiling with the -Wformat warning option (enabled with -Wall) with GCC -- it'll help you catch a lot of easy-to-miss errors often due to typos such as too many arguments, not enough arguments, mismatched format specifiers and arguments, etc.

GCC also has a nifty `format' function attribute which you can use to tag any functions you write that are wrappers around printf/scanf (such as a custom logging function), and it can then check the arguments you pass to that -- see http://gcc.gnu.org/onlinedocs/gcc/Function-Attributes.html#index-g_t_0040code_007bformat_007d-function-attribute-2291 for more info.

mikeash - 2009-07-20 18:53:14

Mon, 20 Jul 2009 18:53:14 GMT

Although strftime's strings look superficially like printf's, they are actually completely different and such do not count. You can argue about what is or is not a "format string", but in this article I was only discussing the ones used by printf and similar functions, and those must always be used with variable arguments (whether in the form of a ... argument or a va_list).

Gwynne Raskind - 2009-07-20 16:01:44

Mon, 20 Jul 2009 16:01:44 GMT

I beg to differ that format strings are always used with variadic arguments. strftime(3) is the most obvious example.

Damien Sorresso - 2009-07-20 11:39:31

Mon, 20 Jul 2009 11:39:31 GMT

Upon a re-read, you're right. I just misinterpreted the sentence the first time.

mikeash - 2009-07-19 09:27:04

Sun, 19 Jul 2009 09:27:04 GMT

I must disagree about the wording. A google search for "is always used with" reveals that the phrase is normally used in the way I did. In other words, "X is always used with Y" means that X implies Y, but not that Y implies X.

Thanks for the article idea, I'll put it on my list.

Damien Sorresso - 2009-07-19 03:27:42

Sun, 19 Jul 2009 03:27:42 GMT

Tiny nitpick.

Format strings are always used with a function (or method) that takes variable arguments. This is important for several reasons.

This sentence makes it seem like all functions which take variable arguments also take format strings. I know that's not what you meant, but a better wording would be "Functions or methods which take format strings always take a variable number of arguments."

That brings up another good Friday Q&A idea. Maybe you should cover implementing a function that uses variadic arguments, some of the pitfalls in doing so, etc. (Maybe even touch on variadic arguments in preprocessor macros.)

Also, Jean-Daniel, NULL and a null pointer are different. A null pointer is a pointer which has been assigned the value NULL. NULL itself is just 0.

Other fun Mac OS X-specific format string tidbits...
* NSString and CFString may be constructed with a format string, and you can specify "%@" to print the description of a Cocoa or CF object, respectively.
* The syslog(3) API allows you to specify "%m" to print the current errno. This does not require a corresponding argument in the argument list, so use with care.

mikeash - 2009-07-18 19:04:20

Sat, 18 Jul 2009 19:04:20 GMT

Conceptually nil and Nil are those types, but practically they don't have to be. In the absence of a real Objective-C language spec it's hard to say exactly what they can or can't be, but we can probably consider them to be equivalent to NULL.

However, it's not a problem for things like NSError **. The fact that NULL (and nil and Nil) can be an integer 0 is only a problem when using varargs. For explicitly typed parameters, the 0 will be converted to the null pointer.

Jordy/Jediknil - 2009-07-18 15:41:06

Sat, 18 Jul 2009 15:41:06 GMT

Huh. I really thought nil was (id)(NULL) and Nil was (Class)(NULL). That would have made everything a little more convenient.

Well, except that a Class is a valid id. And that we use NULL all over the place (NSError **, anyone?).

Peter Bierman - 2009-07-18 08:36:44

Sat, 18 Jul 2009 08:36:44 GMT

Good tips! A suggestion: mention the "solution" for the non-constant format strings vulnerability where you wrote about it. printf("%s", someString);

Vincent Gable - 2009-07-18 07:08:33

Sat, 18 Jul 2009 07:08:33 GMT

Thanks mikeash, that's excellent information!

Something that's been very helpful to me when printf-debugging is using macros to print variables without ever having to mess with format strings. It turns out that 90% of the time I can just say `LOG_ID(name)` and the "name = Vincent" information is all I needed.
Details here:
http://vgable.com/blog/2008/08/05/simpler-logging-2/

Also, Dave Dribin created an excellent DDToNSString() function that can automagically convert a C-type into an NSSString:
http://www.dribin.org/dave/blog/archives/2008/09/22/convert_to_nsstring/

I've been using a modified DDToNSString() in a LOG_EXPR() macro that (mostly) Just Works no matter what type it's given. Once I've worked out a few more kinks, and understand the esoteric build settings it needs, I'll write something up on it.

mikeash - 2009-07-18 03:54:06

Sat, 18 Jul 2009 03:54:06 GMT

Again, size is not what matters, only type. There is no guarantee that the integer 0 will be received correctly if the other side is expecting a pointer, even if they are both the same size. Mixing and matching will work on most systems but could result in bad data or even a crash on some.

Unless POSIX also defines NULL to be a "null pointer" then I'm afraid that definition isn't relevant to the question. All this definition means is that NULL is not necessarily a null pointer.

Jean-Daniel Dupas - 2009-07-18 03:47:52

Sat, 18 Jul 2009 03:47:52 GMT

Doo. I read again the spec and you're right. Nothing tells that sizeof(null pointer constant) == sizeof(void *)

But I managed to find a interesting sentence in POSIX though:

3.244 Null Pointer

The value that is obtained by converting the number 0 into a pointer; for example, (void *) 0. The C language guarantees that this value does not match that of any legitimate pointer, so it is used by many functions that return pointers to indicate an error.

http://www.opengroup.org/onlinepubs/009695399/basedefs/xbd_chap03.html

mikeash - 2009-07-18 02:08:19

Sat, 18 Jul 2009 02:08:19 GMT

Yes, on current OS versions you can do all sorts of things. You can use %lx to print pointers, you can use %ld to print size_t and NSInteger and many other types, and in general you can just look up what the sizes are and use a specifier which mostly matches. Doesn't mean it's a good idea.

Peter Hosey - 2009-07-18 01:35:08

Sat, 18 Jul 2009 01:35:08 GMT

So you are talking about hypothetical future OS versions, then. As you say, these are good to keep in mind.

mikeash - 2009-07-18 01:19:15

Sat, 18 Jul 2009 01:19:15 GMT

Peter Hosey: "Always the same size" is completely irrelevant. Nothing in the standard says that you can pass an integer of one type and retrieve it using a different integer type of the same size, even if this works on most implementations.

You are correct that using %ld will correctly print an NSInteger on all current Cocoa architectures. And two years ago, pointers were always 32-bit on all current Cocoa architectures. Four years ago, integers were always big-endian on all current Cocoa architectures. If you write your code to depend on today's assumptions, your code will break tomorrow.

Numbered argument specifiers are not part of the C standard but they are part of the POSIX standard, so unless you need your code to be portable to non-POSIX platforms you can depend on them to exist. See http://www.opengroup.org/onlinepubs/000095399/functions/printf.html

However my example which mixes numbered specifiers and non-numbered specifiers is not supported at all. It's an all-or-nothing thing.

Jean-Daniel Dupas: I don't believe you're correct that C99 defines NULL as a pointer. The C99 standard is available here: http://www.open-std.org/JTC1/SC22/wg14/www/docs/n1124.pdf

The relevant passages are this:

An integer constant expression with the value 0, or such an expression cast to type void *, is called a null pointer constant.

And:

The macro NULL is defined in <stddef.h> (and other headers) as a null pointer constant; see 7.17.

These both appear on page 47. Thus NULL can be correctly defined as 0, (void *)0, (3 - 3), (void *)(42/43), etc. No statement is made about it being required to be a pointer type as far as I can see.

Peter Hosey - 2009-07-18 01:15:26

Sat, 18 Jul 2009 01:15:26 GMT

Jean-Daniel Dupas:

... no, it does not always have the same size on the current OS X version.

That's not what I said. I said it always has the same size as long on current Mac OS X.

Jose Vazquez - 2009-07-18 00:17:09

Sat, 18 Jul 2009 00:17:09 GMT

Thank you! Interesting, to find out that after so many years of using it there were still so many useful tricks to learn. I have managed to bend printf to my will, but now I have a deeper understanding of it. The Type Promotion stuff in particular just dispelled a lot of magic.

Jean-Daniel Dupas - 2009-07-18 00:08:14

Sat, 18 Jul 2009 00:08:14 GMT

@Peter Hosey : NSInteger is defined as a 32 bit integer on 32 bit arch, and 64 bits integer on 64 bit arch. So no, it does not always have the same size on the current OS X version.

Yes, that means all of the code out there which looks like this is, strictly speaking, wrong:
[NSArray arrayWithObjects:a, b, c, nil];

It depends what you mean by "strictly". The C99 standard define NULL as a pointer, so this code is correct as long as you use a C99 compliant compiler.

foobaz - 2009-07-17 23:52:53

Fri, 17 Jul 2009 23:52:53 GMT

To print a size_t, you can also use %zu, like this:

NSLog(@"lod == %zu", layer.levelsOfDetail);

Peter Hosey - 2009-07-17 23:42:04

Fri, 17 Jul 2009 23:42:04 GMT

Yargh, proofreading fail.

As of Mac OS X, ...

I mean Mac OS X 10.5.7.

Peter Hosey - 2009-07-17 23:41:22

Fri, 17 Jul 2009 23:41:22 GMT

Oh, now I see the problem with the dollar sign feature. Thanks, Dave. Still an extension, though.

Peter Hosey - 2009-07-17 23:40:17

Fri, 17 Jul 2009 23:40:17 GMT

For ... NSInteger you need to get a little cleverer. You can't use %d because [it] might be bigger than an int. You can't use %ld or %lld because [it] might be smaller than those, and type promotion doesn't carry over. [It] could even be bigger than those.

Are you talking about a hypothetical future version of Mac OS X? As of Mac OS X, it's always the same size as a long on all currently-supported architectures. I believe this goes for the iPhone as well.

NULL can legally just be a #define to 0...

Well, it can be. In C++ and Objective-C++, it may be. But in C and Objective-C, it isn't. See the definitions of __DARWIN_NULL in <sys/_types.h>, Nil and nil in <objc/objc.h>, and NULL everywhere that matters.

This is mainly valid as a portability concern: Some other operating system may be more free-wheeling in its headers' definition of NULL, and *then*, it's worth being careful with how you use NULL.

You can actually have any specifier use any argument. This is done by adding $n to the format specifier, where n is the argument number to print.

That's an extension; it's not part of the C99 standard. Moreover, it doesn't even work with printf; it's only available in Core Foundation. (And you forgot a \n in your format string.)

mikeash - 2009-07-17 23:22:11

Fri, 17 Jul 2009 23:22:11 GMT

How embarrassing! Thanks for letting me know. I've fixed up the article.

Dave - 2009-07-17 23:17:38

Fri, 17 Jul 2009 23:17:38 GMT

Very useful, thank you! The only comment I have is about using random access arguments. You have:

printf("a = %$2d b = %$1d", b, a);

When in reality it should be:

printf("a = %2$d b = %1$d", b, a);

The dollar sign should be after the digit.

Cheers,

Dave

Padraig Brady - 2009-07-17 23:03:20

Fri, 17 Jul 2009 23:03:20 GMT

Good info thanks! I find the man pages on linux at least a bit hard to parse, so I created a <a href="http://www.pixelbeat.org/programming/gcc/format_specs.html>;printf crib sheet</a>. I also wrote some notes for printing variable sized ints since they're a common source of confusion: http://www.pixelbeat.org/programming/gcc/int_types/