Messages in this thread | | | Date | Wed, 7 Mar 2012 14:24:39 -0600 | From | Peter Seebach <> | Subject | Re: [PATCH] perf: Incorrect use of snprintf results in SEGV |
| |
On Wed, 7 Mar 2012 13:44:55 -0500 Nick Bowler <nbowler@elliptictech.com> wrote:
> To answer the question, one "solution" here is to run in a loop > allocating larger and larger buffers until ret is strictly less > than len, then (for this function) free the allocated buffer.
Strictly speaking, I am obliged to concede that this does, in fact, result in either success or knowledge that success is impossible in a finite number of iterations. However, the number-of-iterations vs. wasted-space tradeoff is horrible. I appreciate the use of scare quotes around the word "solution". :)
> There are a couple functions in POSIX that work this way (*cough* > readlink *cough*), and it's *ugly*.
The other thing we looked at, I believe, was Microsoft's sprintf_s(), which is the "secure" version. I can't honestly say from reading their docs whether "ran out of space" is an error (resulting in returning -1) or whether it returns the number of bytes written. Either way, it has that same basic problem. Also there's strftime(), which has the brilliant design choice that if it runs out of space, it returns a value which could in fact be a correct return value for at least some possible inputs, and the contents of the buffer are indeterminate. A true feat of software engineering, that.
-s -- Listen, get this. Nobody with a good compiler needs to be justified.
| |