1

Using valgrind I run the following code:

#include <stdio.h>
#include <stdlib.h>

int main(int argc, char** argv){

    printf("Hello World!");

    return EXIT_SUCCESS;
}

The valgrind output is:

 HEAP SUMMARY:
 ==22613==     in use at exit: 0 bytes in 0 blocks
 ==22613==   total heap usage: 1 allocs, 1 frees, 1,024 bytes allocated

Why does the printf statement allocate 1,024 bytes on the heap?

Daniel
  • 43
  • 1
  • 8
  • Does it allocate anything if you do `fprintf(stdout, "Hello Wolrd!\n");`? – Iharob Al Asimi Mar 23 '17 at 02:55
  • Yes, I get the same result... – Daniel Mar 23 '17 at 02:56
  • Nope, in that case there are 0 allocations. Is there a way to see what is allocated, or more info with valgrind? – Daniel Mar 23 '17 at 02:59
  • I can't reproduce this! I noticed a few days ago that `puts()` allocated some bytes, but `printf()` doesn't. Are you linking to some library? – Iharob Al Asimi Mar 23 '17 at 02:59
  • So the whole test.c file is the code you see above, I'm running it on the Uni's machine – Daniel Mar 23 '17 at 03:01
  • Maybe the string literal is stored in the heap? – John Coleman Mar 23 '17 at 03:01
  • @JohnColeman It allocated 1024 bytes. – Iharob Al Asimi Mar 23 '17 at 03:02
  • @Daniel, What about compilation flags? What if you do `gcc -S` and check what is being generated really? `printf()` is in general a complex function, but printing a string literal should not generate something too complicated I guess. – Iharob Al Asimi Mar 23 '17 at 03:03
  • 1
    I stand corrected, In fact, I can see exactly the same behavior. – Iharob Al Asimi Mar 23 '17 at 03:04
  • 1024 seems like overkill for whatever it is doing, like it is allocating more space than is needed. – John Coleman Mar 23 '17 at 03:05
  • I tried it with a much longer string, same amount or memory allocated. – Daniel Mar 23 '17 at 03:05
  • Here's the -S http://pastebin.com/JAftTirW – Daniel Mar 23 '17 at 03:07
  • 1
    First, did you try without the printf? It could also be the runtime library setup for `main()` doing the allocation; maybe making a copy of the environment. If it really is printf, it's probably allocating an initial buffer for format expansion. But these are just guesses. Do some work: get the source for your C library including the printf you're using. Study it to find what's happening. You'll learn something. – Gene Mar 23 '17 at 03:08
  • 1
    Same with extremely long str. I did try without printf, no issue then. How do I get the library C source? – Daniel Mar 23 '17 at 03:08
  • the total allocation grows and the # of allocs increases. – Daniel Mar 23 '17 at 03:12
  • 2
    @Daniel printf: https://sourceware.org/git/?p=glibc.git;a=blob;f=stdio-common/printf.c vfprintf: https://sourceware.org/git/?p=glibc.git;a=blob;f=stdio-common/vfprintf.c –  Mar 23 '17 at 03:13
  • @Jerry Thanks for the code. Some execution paths definitely do allocate a block of dynamic memory and do what essentially amounts to calling a backend equivalent to `vsprintf()` to interpret the format string, and then printing the buffer. E.g. the line `return buffered_vfprintf (s, format, ap);` One reason to keep the buffer around might be so that you can still print an error message if you run out of memory. – Davislor Mar 23 '17 at 04:25

0 Answers0