On Mon, 27 Nov 2017 00:42:01 +0000, Theo de Raadt wrote: > This needs worst-case performance measurements.
The only instances where performance could be a problem are in vfprintf.c and vfwprintf.c, where the calls happen inside a loop; but for these, in fact, the best solution would be to use recallocarray directly: rather than repeatedly freeing (and clearing) `convbuf' and reallocating a fresh one every time it is needed, it should be kept around and passed to __wcsconv() and __mbsconv(), along with some accounting of its current size, so that these functions could then call recallocarray appropriately. However, this optimisation would be more intrusive than the diff I submitted, and would therefore demand greater familiarity with stdio's source, which I have not yet acquired. That being said, in all other cases, since the way stdio functions fill their buffers is much more costly than simply writing a bunch of zeros in sequence (or merely calling munmap(2)), no real slowdown is to be expected. I should also point out that recallocarray is currently used inside several loops in fvwrite.c, fgetln.c and getdelim.c, but no one complained that the affected functions became too slow, because doing things, as stdio does, like reading from and writing to disk or decoding and converting user input will always dominate the effect of a few calls to discard temporary buffers. Regards, kshe
