> snprintf() has the advantage that there was no sane way to use sprintf()
> securely -- you couldn't tell how big a buffer it would need in the
> general case without reimplementing the guts of sprintf() yourself.
I'm not sure how long glibc has had open_memstream(), but you could've done it with that and fprintf() instead... Or, asprintf(), if that's been around longer... Or, hell, you could always have just fprintf()'d to a temp file, checked the size, allocated a buffer, and read the file back in... Oh, wait, you said "sane"... ;-)
I just thought the same "Oh noes, truncation!!!" worries applied to snprintf(), as well... And, frankly, I haven't heard of that causing major security nightmares anywhere yet... Has it?
Posted Jul 19, 2012 23:11 UTC (Thu) by nix (subscriber, #2304)
[Link]
I said 'sane' but I assumed 'portable': this stuff had to run on Solaris as well as Linux. Neither asprintf() nor open_memstream() are portable, alas.
The ups and downs of strlcpy()
Posted Jul 20, 2012 10:09 UTC (Fri) by RobSeace (subscriber, #4435)
[Link]
Ah, I thought we were just talking about the rationale for getting accepted into glibc or not... Was it just that snprintf() was accepted by POSIX/ISO, so glibc was forced to accept it as a standard, while strl*() wasn't?
The ups and downs of strlcpy()
Posted Jul 20, 2012 12:44 UTC (Fri) by nix (subscriber, #2304)
[Link]
Ah, right. From a *user's* perspective we cannot use open_memstream() et al because they are not portable. From a *library developer's* perspective we shouldn't introduce strlcpy() because it sucks and everyone should just use open_memstream(). :)
Obviously the only real solution is to write your own string abstraction using counted strings or whatever floats your boat...