Jeffrey Walton <noloader@xxxxxxxxx> writes: > Yeah, I think you are right about asprintf (though I have never used it). > I can't count how many times I've seen silent truncation due to sprint. > Most recently, I pointed it out on some SE Android patches (Android port > of SE Linux) that passed by the NSA sponsored mailing list. They went > unfixed. Amazing. Silent truncation is the primary reason why strlcpy and strlcat aren't in glibc. Both functions are designed to silently truncate when the target buffer isn't large enough, and few callers deal with that. This ironically can actually create other types of security vulnerabilities (although it's probably less likely to do so than a stack overflow). asprintf guarantees that you don't have silent truncation; either you run out of memory and the operation fails, or you get the whole string. The cost, of course, is that you now have to do explicit memory management, which is often what people were trying to avoid by using static buffers. But it *is* C; if you're not going to embrace explicit memory management, you may have picked the wrong programming language.... :) strlcpy and strlcat have some benefit in situations where you're trying to add some robustness (truncation instead of overflow) to code with existing, broken APIs that you can't change, which I suspect was some of the original motivation. But if you can design the APIs from the start, I'd always use strdup and asprintf (or something more sophisticated like obstacks or APR pools) instead. -- Russ Allbery (rra@xxxxxxxxxxxx) <http://www.eyrie.org/~eagle/> _______________________________________________ Autoconf mailing list Autoconf@xxxxxxx https://lists.gnu.org/mailman/listinfo/autoconf