gcc and printf/puts optimizations

Posted by Nico Golde in
Thursday, September 17. 2009

Today I had a nice WTF moment. I was looking into when gcc is going to print (null) rather than segfaulting on trying to dereference a NULL pointer. I knew newer gcc versions are doing that in some situations. But it turns out this is more complex than I initially thought.

So here we have 5 little test programs:

#include <stdio.h>
int main(void){
printf("%s\n", NULL);
return 0;
}

#include <stdio.h>
int main(void){
printf("%s\n", 0);
return 0;
}

#include <stdio.h>
int main(void){
printf("%s", NULL);
return 0;
}

#include <stdio.h>
int main(void){
printf("%s", 0);
return 0;
}

#include <stdio.h>
int main(void){
printf("bla: %s\n", NULL);
return 0;
}

Now I expected some kind of consistent behaviour at least apart from the last snippet as from the C programming point of view the source does exactly the same. But it seems this is not the case.

The first snippet is straightforward, even in the generated assembler the code dereferences a NULL pointer in puts and therefore results in a segfault. But wasn't it printf from the GNU libc that replaces such cases with (null)? Yes it was but it turns out only in some cases. Now here is the fun part. If we look at the generated code for the first example we see:

00000000004004ec <main>:
4004ec: 55 push %rbp
4004ed: 48 89 e5 mov %rsp,%rbp
4004f0: bf 00 00 00 00 mov $0x0,%edi
4004f5: e8 e6 fe ff ff callq 4003e0 <puts@plt>

Huh? puts? Now that is interesting. It seems like gcc sees the format string "%s\n" and after that a pointer (void *) so it assumes the usage of puts does make sense so it optimizes the call.
Now for the second code snippet this is not the case:

00000000004004ec <main>:
4004ec: 55 push %rbp
4004ed: 48 89 e5 mov %rsp,%rbp
4004f0: be 00 00 00 00 mov $0x0,%esi
4004f5: bf fc 05 40 00 mov $0x4005fc,%edi
4004fa: b8 00 00 00 00 mov $0x0,%eax
4004ff: e8 dc fe ff ff callq 4003e0 <printf@plt>

In this case gcc sees the format string and an integer so it can't just use this with puts in a way that makes sense. printf is used and the result is (null).

Until this point the behaviour is somehow predictable at least if you know that.
But it becomes even more strange. The third and the fourth example both result in the usage of printf and therefore the displayed result is (null). In my opinion it seems that gcc is testing exactly for "%s\n" (as puts prints a newline at the end anyway). So these two examples don't segfault as well. If there's a newline gcc is - or at least that's my impression - already concatenating the format string with the pointer value.

In the last case the newline is present again. However there is a leading string in front of the format string %s. Here gcc is not seeing this as a whole thing concatenating it and calling puts. It's using printf again and results bla: (null).

I have no idea what the reason behind this behaviour is, I guess there are good arguments for that by the gcc people. But honestly, it SUCKS and is highly inconsistent, *grrr*. The whole behaviour isn't even consistent between different gcc versions.

The above results are tested with gcc (Debian 4.3.4-2) 4.3.4. I also tested with gcc (GCC) 3.4.3, in this case all of the above examples result in a segmentation fault (not sure when this (null) replacement feature in the glibc was introduced though). You can also disable this "optimization" by using -fno-builtin-printf btw.

Comments (3) - Trackbacks (0)

Defined tags for this entry: c, compiler, gcc, optimization, programming, rant, wtf

Related entries by tags:

Trackbacks

Trackback specific URI for this entry

No Trackbacks

Comments

Display comments as (Linear | Threaded)

If I understand the above correctly, the only case that is changed/optimized by certain gcc versions is the printf("%s\n", (char*)) case. This is certainly because if the format string is different, or an int arg follows, it can not be replaced by puts. That logic appears consistent to me.

Furthermore, your statement "even in the generated assembler the code dereferences a NULL pointer and therefore results in a segfault" is not true, as there is only "mov $0x0,%edi" which means loading a value into a register. The dereferencing and segfault happens within the puts function.

Ciao
Bernhard M.

#1 Bernhard M. (Homepage) on 2009-09-20 08:09 (Reply)

it is not consistent from a users perspective and it's not documented either, at least i don't know of any documentation. it is confusing. I am not saying it doesn't make sense. Consistency to me would mean to use puts whenever there's a (char *) or not using it at all. Of course you're right with the null ptr dereference, it happens of course in puts, the original text was a bit misleading regarding that.

Btw in the meantime I found another intersting document exploring this: http://www.ciselant.de/projects/gcc_printf/gcc_printf.html

#1.1 nion on 2009-10-09 00:39 (Reply)

Maybe the best fix would be to teach puts to handle NULL, too (string written as array below to avoid comment escaping bug).

diff --git a/libio/ioputs.c b/libio/ioputs.c
index 7fa5db5..c6478e4 100644
--- a/libio/ioputs.c
+++ b/libio/ioputs.c
@@ -31,9 +31,17 @@
+static const char null[] = { '(', 'n', 'u', 'l', 'l', ')', 0 };
+
int
_IO_puts (str)
const char *str;
{
int result = EOF;
- _IO_size_t len = strlen (str);
+ _IO_size_t len;
+
+ if (str == NULL)
+ str = null;
+ len = strlen (str);
+
_IO_acquire_lock (_IO_stdout);
if ((_IO_vtable_offset (_IO_stdout) != 0

#2 Jonathan Nieder on 2010-05-27 02:24 (Reply)

Add Comment

Name
Email
Homepage
In reply to
Comment	Enclosing asterisks marks text as bold (word), underscore are made via _word_. Standard emoticons like :-) and ;-) are converted to images. You can use [geshi lang=lang_name [,ln={y\|n}]][/geshi] tags to embed source code snippets. E-Mail addresses will not be displayed and will only be used for E-Mail notifications. To prevent automated Bots from commentspamming, please enter the string you see in the image below in the appropriate input box. Your comment will only be submitted if the strings match. Please ensure that your browser supports and accepts cookies, or your comment cannot be verified correctly. Enter the string from the spam-prevention image above: You can use [geshi lang=lang_name [,ln={y\|n}]][/geshi] tags to embed source code snippets.
	Remember Information?

gcc and printf/puts optimizations

nion's blog

gcc and printf/puts optimizations

Calendar

Quicksearch

Support

Recent Entries

Archives

Syndicate This Blog

Categories

Tag cloud