Re: vfprintf.c bugfix

[Remco Treffkorn <remco@rvt.com>]

On Saturday 12 July 2003 14:48, Ethan Benson wrote:
> On Sat, Jul 12, 2003 at 12:55:36PM -0700, Remco Treffkorn wrote:
> > On Saturday 12 July 2003 01:32, Ethan Benson wrote:
...
> the problem with that is prom-libc won't compile with gcc-2.95
> anymore.  compilers prior to 3.* only define __va_copy() not
> va_copy().  as you saw in the changelog entry i plan to change that
> when gcc prior to 3 is no longer in common use.  (which means after
> debian releases the successor to woody.)
>
> i could add some ugly ifdef checking for older compilers and then
> doing a #define va_copy __va_copy, but this seems ugly to me, and
> where would i put such crap?  (if we are forced to add similar crud
> for other cases like this later then it would make sense, but atm this
> is the only compiler backward compatibility issue im aware of).
>

Makes sense.
...
> > 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)
>
> is there any way to get the size other then calling vsnprintf?

Not at a cheaper cost. And if you ever single stepped through it, you'd know 
what a jungle it is ;-)

> > 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.
>
> i might do it your way, but with a smaller array.  yaboot 1 used a
> 1024 byte array until some of my later releases where i moved it to
> 2048, without apparent problems (but i can't be sure, yaboot is full
> of strange unexlainable and undebuggable behavior).  with yaboot1
> though if you try to printf something larger then that buffer you just
> end up scribbling all over the stack, and eventually everything else.

I thought the buffer a bit excessive. Most lines are shorter than 132 chars.
Vsnprintf will not write more than buffersize chars anyway, no fear of a 
buffer overrun. I would go 256 bytes even. This way you have at least a 
reasonable expectation tha the vasprintf branch will be executed in your life 
time. Without mm stack overuse is a big problem.

> i would also not call the two variables the same thing, i don't see
> any reason they need to be.

But then there is no point in sending it to the 'obfuscated C' contest :-)

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