This discussion on Hacker News revolves primarily around the nuances and potential pitfalls of C's snprintf function, and the existence of alternative, often more convenient, functions for string formatting and memory management.
The Ambiguity of snprintf's Size Parameter and Return Value
A significant portion of the conversation is dedicated to clarifying the behavior of snprintf, specifically regarding what the size parameter includes and what the function's return value signifies. This ambiguity is seen as a source of confusion and potential bugs.
Users point out that the size parameter in snprintf is meant to include the null terminator, which can be counter-intuitive when users expect to add 1 for the null byte.
"I have size_with_nul because snprintf man pages say ... The functions snprintf() and vsnprintf() write at most size bytes (including the terminating null byte (‘\0’)) to str. If 'size' includes the null byte, why do we have to add 1?" (hdjrudni)
The return value of snprintf is also a point of discussion. It returns the number of characters that would have been written if the buffer were large enough, excluding the null byte. This is crucial for determining the required buffer size but can be misinterpreted.
"The initial call with size 0 tells you the necessary length of the buffer for the string you want, but does not include the null byte." (king_geedorah)
"For clarity, all snprintf calls 'return the number of bytes that would be written to s had n been sufficiently large excluding the terminating null byte' [1]." (orbisvicis)
This distinction is highlighted as a common source of errors, particularly when the returned value is directly used as the length of the written string.
"I’d argue this is one of the cursed design choices of the standard library. Way to easy to use the returned value as the “actual length” of the written string. Sure, that was never the intent, but still…" (BobbyTables2)
The Difficulty of Appending and Managing Formatted Strings in C
The discussion extends to the general challenges of string manipulation in C, specifically appending formatted strings to existing ones. Users express frustration that what seems like a simple operation often requires multiple lines of code and careful error handling.
"The standard library also makes appending a formatted string to an existing one surprisingly nontrivial… What should be a 1-liner is about 5-10 lines of code (to include error handling) and is somewhat hard to read. The “cognitive load” for basic operations shouldn’t be high…" (BobbyTables2)
The Utility and Availability of asprintf and vasprintf
A strong theme that emerges is the recommendation and discussion of asprintf and vasprintf as superior alternatives to snprintf for many use cases, particularly when dynamic buffer allocation is needed. These functions allocate a sufficiently sized buffer (which must then be freed) and return the number of characters written.
"There are
asprintfandvasprintf(takes a va_list argument). Those allocate a sufficiently sized buffer that can be released withfree." (st_goliath)
While asprintf is acknowledged as a GNU extension, users note its widespread adoption across various BSDs, Musl, and increasingly as part of POSIX standards, making it a de facto standard for many developers.
"Yes, it's a GNU extension, but it's also supported by various BSDs [1][2][3], and yes, Musl has it too. It's present in pretty much any sane C library." (st_goliath)
"asprintf and vasprintf are part of POSIX, now." (wahern)
The discovery of asprintf leads to positive reactions, with users appreciating learning about solutions to their current problems.
"Thanks, first I've heard of them and they happen to solve a real problem I'm working on today. Always nice when you can learn something new..." (bluGill)
Some developers also mention creating their own sprintf-like functions that handle memory allocation, demonstrating a community practice of building utility functions when standard ones are insufficient.
"You don't really need to, TBH. I pretty much always wrote a malloc-memory
sprintfalternative if the system didn't have one. it's only a few lines of code, that'll take maybe 10m of your day the first time you realisesprintfon the platform doesn't exist." (lelanthran)
Best Practices for String Formatting and Memory Safety
The discussion indirectly touches upon best practices for string formatting and memory management in C. The complexity and potential for buffer overflows or underflows with snprintf underscore the importance of understanding its exact behavior.
The suggestion to use __attribute__((cleanup)) with dynamically allocated strings (like those from asprintf) is mentioned as a way to ensure automatic memory deallocation, a feature that is expected to become standardized in C2x.
"And combine it with attribute((cleanup)) to get the string automatically freed at the end of your function (if that's the right thing to do). Looks like cleanup with be standardized finally in the next C2x." (rwmj)
One user proposes a custom helper function for asprintf that addresses memory reuse and avoids unnecessary allocations by first formatting into a temporary buffer.
"1. have it free the passed-in buffer, so that you can reuse the same pointer 2. have it do step 1 after the formatting, so the old value can be a format argument 3. when getting the size of the full expansion, don't format to NULL, but do it to a temp buffer (a few KB in size) - then if the expansion is small enough, you can skip the second format into the actual buffer. Just malloc and memcpy. You know how many chars to memcpy, because that's the return value from snprintf" (tom_)
The discussion also highlights the critical nature of "reading the manual" (RTFM) and understanding platform-specific variations in C functions, as subtle differences can lead to significant security vulnerabilities.
"The lost art of RTFM." (ygritte)
"Always read the docs of your system. All of the xxprintf functions are not the same. They are sneaky and look the same on the surface. Even silly things like what the % items do can vary between platforms, or have different meanings, or be missing all together." (sumtechguy)
The potential consequences of misusing snprintf are illustrated with a reference to the CitrixBleed vulnerability, which involved memory leaks in a C-based web server, underscoring the real-world impact of these seemingly small details.
"Cisco and many of Ciscro's customers found out the hard way (during CitrixBleed, ...), leaking random blocks of memory in the proprietary, C-based web server of their security appliance that gets compromised every now and then." (jeroenhd)