Why use asprintf() instead of sprintf()?

Question

I'm having a hard time understanding why you would need asprintf. Here in the manual it says

The functions asprintf() and vasprintf() are analogs of sprintf(3) and vsprintf(3), except that they allocate a string large enough to hold the output including the terminating null byte, and return a pointer to it via the first argument. This pointer should be passed to free(3) to release the allocated storage when it is no longer needed.

So here is the example that I'm trying to understand:

asprintf(&buffer, "/bin/echo %s is cool", getenv("USER"));

What's the difference if the buffer allocates a string large enough vs saying char* = (string)

Carri

asprintf() and vasprintf() are GNU extensions. Added the GNU tag. – Apostatize

Hmm, I wonder if the asker is doing the exercises here: exploit-exercises.com/nebula/level02? – If

A very good blog post about this topic can be found here: memory-management-in-c-and-auto ... btw. the complete blog is worthwhile reading – Aden

@If OpenBSD has it too. NetBSD too. The FreeBSD man page has some details about its history: "The functions asprintf() and vasprintf() first appeared in the GNU C library. These were implemented by Peter Wemm in FreeBSD 2.2, but were later replaced with a different implementation from OpenBSD 2.3 by Todd C. Miller." – Doble

It is hard to understand why you don't see the difference - with sprintf you have to calculate string length, allocate memory, then do sprintf in buffer. asprintf directly returns a pointer. – Baalbeer

Answer 1

If you use sprintf() or vsprintf(), you need to allocate a buffer first, and you need to be sure that the buffer is large enough to contain what sprintf writes. Otherwise sprintf() will happily overwrite whatever memory lies beyond the end of the buffer.

char* x = malloc(5 * sizeof(char));
// writes "123456" +null but overruns the buffer
sprintf(x,"%s%s%s", "12", "34", "56");

... writes the '6' and the terminating null beyond the end of the space allocated to x, either corrupting some other variable, or causing a segmentation fault.

If you're lucky, it will trample on memory in-between allocated blocks, and will do no harm -- this time. This leads to intermittent bugs -- the hardest kind to diagnose. It's good to use a tool like ElectricFence that causes overruns to fail-fast.

A non-malicious user who provides an overlong input, could cause the program to behave in unexpected ways. A malicious user could exploit this as a way to get their own executable code into the system.

One guard against this is to use snprintf(), which truncates the string to the maximum length you supply.

char *x = malloc(5 * sizeof(char));
int size = snprintf(x, 5, "%s%s%s", "12", "34", "56"); // writes "1234" + null

The return value size is the length that would have been written if space was available -- not including the terminating null.

In this case, if size is greater than or equal to 5 then you know that truncation occurred - and if you didn't want truncation, you could allocate a new string and try snprintf() again.

char *x = malloc(BUF_LEN * sizeof(char));
int size = snprintf(x, 5, "%s%s%s", "12", "34", "56");
if (size >= BUF_LEN) {
    realloc(&x,(size + 1) * sizeof(char));
    snprintf(x, size + 1 , "%s%s%s", "12", "34", "56");
}

(That's a pretty naive algorithm, but it illustrates the point. There may yet be bugs in it, which further illustrates the point -- this stuff is easy to screw up.)

asprintf() does this in one step for you - calculates the length of the string, allocates that amount of memory, and writes the string into it.

char *x;
int size = asprintf(&x, "%s%s%s", "12", "34", "56");

In all cases, once you've finished with x you need to release it, or you leak memory:

free(x);

asprintf() is an implicit malloc(), so you have to check it worked, just as you would with malloc() or any other system call.

if (size == -1 ) {
   /* deal with error in some way */
}

Note that asprintf() is part of the GNU and BSD extensions to libc - you can't be sure it will be available in every C environment. sprintf() and snprintf() are part of the POSIX and C99 standards.

Distefano

Thank you for this answer. Cleared up a lot of things – Carri

Also, you should not cast the result of malloc (and family) in C. – Echolalia

Wait, if size is the characters written without the terminating null, shouldn't you realloc (size+1) * sizeof(char)? – Intercommunicate

@JoachimSauer thanks. Ah, C :) -- at least it demonstrates why asprintf is useful. The old way is really easy to screw up. – Distefano

It is worth noting that asprintf is not part of the C or POSIX standards, and is a GCC and BSD extension. Although useful - which is what the question asked - it should be used fully aware that your C code's portability goes way down. linux.die.net/man/3/asprintf – Kenner

Relented, 5 years later, and removed the casts on malloc() – Distefano

I think I found a few problems in the snprintf snippet: 1. You want to pass BUF_LEN to the first snprintf(), not 5! 2. You need to do x = realloc(x, (size + 1))! realloc accepts a pointer, not a pointer to a pointer! 3. The second snprintf call should be (size+1), not 5! – Sinhalese

Answer 2

The benefit is security.

Numerous programs have allowed system exploits to occur by having programmer-supplied buffers overflowed when filled with user supplied data.

Having asprintf allocate the buffer for you guarantees that can't happen.

However you must check the return value of asprintf to ensure that the memory allocation actually succeeded. See http://blogs.23.nu/ilja/2006/10/antville-12995/

Thigmotropism

I remember reading on this vaguely. Is this the only reason to use asprintf? – Carri

@BrandonLing well, in many cases it would make your code shorter, too! – Thigmotropism

@BrandonLing: It removes code duplication -- many times when you want a never-truncating sprintf you're forced to write your own function that does this anyway, so now you have it all wrapped up in a single, ready-made function, at the cost of portability. – Yorker