| |||||||||||||
The ups and downs of strlcpy()The ups and downs of strlcpy()Posted Jul 19, 2012 22:08 UTC (Thu) by nix (subscriber, #2304)In reply to: The ups and downs of strlcpy() by RobSeace Parent article: The ups and downs of strlcpy()
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. You couldn't do it by tracking some extra value, the way you can with string lengths. snprintf() lets you do it with two calls, one with a tiny size, then one with the size returned from the previous call, plus one. Much better.
(Log in to post comments)
The ups and downs of strlcpy() Posted Jul 19, 2012 22:44 UTC (Thu) by RobSeace (subscriber, #4435) [Link]
> 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?
The ups and downs of strlcpy() 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...
|
|||||||||||||