By Deepanjan Mazumdar

2012-07-21 04:02:39 8 Comments

Came across an interesting interview question:

test 1:
printf("test %s\n", NULL);
printf("test %s\n", NULL);

test (null)
test (null)

test 2:
printf("%s\n", NULL);
printf("%s\n", NULL);
Segmentation fault (core dumped)

Though this might run fine on some systems, atleast mine is throwing a segmentation fault. What would be the best explanation of this behavior? Above code is in C.

Following is my gcc info:

[email protected]:~$ gcc --version
gcc (Ubuntu/Linaro 4.6.3-1ubuntu5) 4.6.3


@Jonathan Leffler 2012-07-21 04:36:21

Section 7.1.4 (of C99 or C11) says:

§7.1.4 Use of library functions

¶1 Each of the following statements applies unless explicitly stated otherwise in the detailed descriptions that follow: If an argument to a function has an invalid value (such as a value outside the domain of the function, or a pointer outside the address space of the program, or a null pointer, or a pointer to non-modifiable storage when the corresponding parameter is not const-qualified) or a type (after promotion) not expected by a function with variable number of arguments, the behavior is undefined.

Since the specification of printf() says nothing about what happens when you pass a null pointer to it for the %s specifier, the behaviour is explicitly undefined. (Note that passing a null pointer to be printed by the %p specifier is not undefined behaviour.)

Here is the 'chapter and verse' for the fprintf() family behaviour (C2011 — it is a different section number in C1999):

§ The fprintf function

s     If no l length modifier is present, the argument shall be a pointer to the initial element of an array of character type. [...]

     If an l length modifier is present, the argument shall be a pointer to the initial element of an array of wchar_t type.

p     The argument shall be a pointer to void. The value of the pointer is converted to a sequence of printing characters, in an implementation-defined manner.

The specifications for the s conversion specifier preclude the possibility that a null pointer is valid since the null pointer does not point to initial element of an array of the appropriate type. The specification for the p conversion specifier does not require the void pointer to point at anything in particular and NULL is therefore valid.

The fact that many implementations print a string such as (null) when passed a null pointer is a kindness that is dangerous to rely upon. The beauty of undefined behaviour is that such a response is permitted, but it is not required. Similarly, a crash is permitted, but not required (more's the pity – people get bitten if they work on a forgiving system and then port to other less forgiving systems).

@ouah 2012-08-05 11:47:00

Since the specification of printf() says nothing about what happens when you pass a null pointer to it for the %s specifier, the behaviour is explicitly undefined. actually it says the argument shall be a pointer to the initial element of an array of character type and the standard says the violation of a shall that appears outside of a constraint is undefined behavior (C99, 4.p2).

@Jonathan Leffler 2012-08-05 13:30:45

@ouah: is what you're saying different from the quoted section of §7.1.4 says ('null pointer ... behaviour is undefined'), or what I say it says ('null pointer ... behaviour is explicitly undefined')?

@ouah 2012-08-05 13:49:54

I'm adding this as an extra note: that 4.p2 could be also used with the specification of printf to show that the call with the NULL argument is UB. In my comment the word actually is maybe superfluous.

@Chris Reuter 2012-07-21 04:31:38

First things first: printf is expecting a valid (i.e. non-NULL) pointer for its %s argument so passing it a NULL is officially undefined. It may print "(null)" or it may delete all files on your hard drive--either is correct behavior as far as ANSI is concerned (at least, that's what Harbison and Steele tells me.)

That being said, yeah, this is really wierd behavior. It turns out that what's happening is that when you do a simple printf like this:

printf("%s\n", NULL);

gcc is (ahem) smart enough to deconstruct this into a call to puts. The first printf, this:

printf("test %s\n", NULL);

is complicated enough that gcc will instead emit a call to real printf.

(Notice that gcc emits warnings about your invalid printf argument when you compile. That's because it long ago developed the ability to parse *printf format strings.)

You can see this yourself by compiling with the -save-temps option and then looking through the resulting .s file.

When I compiled the first example, I got:

movl    $.LC0, %eax
movl    $0, %esi
movq    %rax, %rdi
movl    $0, %eax
call    printf      ; <-- Actually calls printf!

(Comments were added by me.)

But the second one produced this code:

movl    $0, %edi    ; Stores NULL in the puts argument list
call    puts        ; Calls puts

The wierd thing is that it doesn't print the following newline. It's as though it's figured out that this is going to cause a segfault so it doesn't bother. (Which it has--it warned me when I compiled it.)

@Keith Thompson 2012-07-21 04:59:14

Good answer (though R. beat you by a few minutes). But there's nothing weird about the newline. puts() prints the argument string to stdout followed by a newline. (By contrast, fputs() prints to a specified file and doesn't add a newline.)

@Chris Reuter 2012-07-21 20:52:31

Huh. I didn't know about the newline until you told me. I guess it's because I always just used fputs instead.

@R.. 2012-07-21 04:23:46

As far as the C language is concerned, the reason is that you're invoking undefined behavior and anything can happen.

As for the mechanics of why this is happening, modern gcc optimizes printf("%s\n", x) to puts(x), and puts does not have the silly code to print (null) when it sees a null pointer, whereas common implementations of printf have this special case. Since gcc can't optimize (in general) non-trivial format strings like this, printf actually gets called when the format string has other text present in it.

@Mysticial 2012-07-21 04:24:42

This is what I was looking for. +1

@darth_coder 2014-02-15 07:22:55

Is this behaviuor calling puts and printf in different scenario part of C standard. Or a compiler can chose its own mechanisms. Since on visual c++ it works fine.

@R.. 2014-02-15 17:42:14

The compiler can make any transformation that does not change the behavior of a valid program. (Here it changed the behavior of an invalid one.)

@Yunchi 2012-07-21 04:13:10

The NULL pointer doesn't point to any address, and attempting to print it causes undefined behavior. Undefined meaning it's up to your compiler or C library to decide what to do when it tries to print NULL.

Related Questions

Sponsored Content

4 Answered Questions

[SOLVED] What does the C ??!??! operator do?

  • 2011-10-19 16:56:59
  • Peter Olson
  • 228146 View
  • 1719 Score
  • 4 Answer
  • Tags:   c operators trigraphs

13 Answered Questions

[SOLVED] What is the effect of extern "C" in C++?

5 Answered Questions

[SOLVED] What is ":-!!" in C code?

31 Answered Questions

3 Answered Questions

[SOLVED] segmentation fault in printf

1 Answered Questions

[SOLVED] Does malloc allocate more than I ask for?

2 Answered Questions

[SOLVED] Replacing a character using pointer in ANSI C

  • 2013-11-10 23:46:16
  • thilip kumar
  • 1007 View
  • 0 Score
  • 2 Answer
  • Tags:   c string pointers

2 Answered Questions

[SOLVED] Passing Structures by Reference

1 Answered Questions

[SOLVED] libstdc++ crashing in ubuntu 64 bit

  • 2013-02-25 12:46:02
  • Wagmare
  • 1091 View
  • 0 Score
  • 1 Answer
  • Tags:   c++ linux

Sponsored Content