I am not sure that you've correctly identified the cause, though. Looking at the disassembled machine code for both function calls, I found that 'printf("%s\n")' isn't handled by printf() at all -- the compiler inserts a call to puts() instead. puts(), in turn, calls strlen(), passing it a null pointer, which strlen() tries to dereference. Hence, the segmentation fault.
One more thing: Is this actually a bug? I mean, the inconsistency is due to gcc's substituting puts() for printf(). Calling puts() with a null pointer results in a segfault. But isn't it the programmer's job to make sure that he doesn't accidentally pass a null pointer to puts() -- or to printf("%s\n") for that matter?
Anyway, since I can reproduce this, I am marking this as confirmed.
I can confirm this behaviour.
I am not sure that you've correctly identified the cause, though. Looking at the disassembled machine code for both function calls, I found that 'printf("%s\n")' isn't handled by printf() at all -- the compiler inserts a call to puts() instead. puts(), in turn, calls strlen(), passing it a null pointer, which strlen() tries to dereference. Hence, the segmentation fault.
One more thing: Is this actually a bug? I mean, the inconsistency is due to gcc's substituting puts() for printf(). Calling puts() with a null pointer results in a segfault. But isn't it the programmer's job to make sure that he doesn't accidentally pass a null pointer to puts() -- or to printf("%s\n") for that matter?
Anyway, since I can reproduce this, I am marking this as confirmed.