Re: vfprintf.c bugfix

[Remco Treffkorn <remco@rvt.com>]

On Saturday 12 July 2003 01:32, Ethan Benson wrote:
> On Fri, Jul 11, 2003 at 12:00:44PM -0700, Remco Treffkorn wrote:
>
> i fixed vAsprintf, ages ago, not vFprintf.
>

Oh, you were not talking about the same thing. Missed that.

...

Before we go on:
I can live with your fix, since it is (mostly) correct. Mine was incomplete.
My only issue with correctness is your use of __va_copy without the matching 
va_end. What you do is correct in the sense that it works with gcc on 
powerpc, where va_end is basically a nop. I don't know if gcc on any platform 
requires the use of va_end, but the man page calls for it in no uncertain 
terms. I would suggest using va_copy over __va_copy, and making the spec 
happy by providing the appropriate va_end.
 
> > Here is the point: I feel like an idiot now, but am almost intimidated
> > enough not to ask, but here it goes: what are you talking about? What
> > array is around persistently? I am not trying to be annoying, I really
> > don't get it.

> well im not completly sure, but my understanding is that a variable is
> disposed of outside of if () statements, so it shouldn't waste space
> on the stack in theory (i could be wrong, im no expert on stack usage
> stuffs).
>

Auto variables exist on the stack. The compiler basically just decrements the 
stack pointer by the size of the object and keeps track of its location.

Autos are created when you enter the block. The way you have it, the space for 
buf is created when you enter the if{} block. When you exit the block, the 
stack pointer is restored and buf becomes invisible.

Although I am advocating beeing frugal with resources, in this case it has low 
priority, because the general case is that the string will fit, and thus you 
enter the if block and use buf on the stack anyway.

> also i don't like the idea of creating a 4096 byte array then turning
> around and changing it into a pointer to malloced space like your code
> does.

Variable names are shadowed all the time, but I agree with you: Just because 
it can be done does not mean it should be done.

Here is what really irks me:

In the simple case (string fits in buf) you call vsnprintf twice. Once just to 
get the length of the resulting string, and then again to actually create the 
string. Why not just call vsnprintf once to do the work, then checking if 
everythig fit, and if not then use vasprintf. (Oh, and vasprintf calls 
vsnprintf again to get the size)

This way the general case is not penalized, but the complex case.
But this is not really a fix, so feel free to ignore it.

-- 
Remco Treffkorn (RT445)
HAM DC2XT
remco@rvt.com   (831) 685-1201