[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: vfprintf.c bugfix



On Fri, Jul 11, 2003 at 12:00:44PM -0700, Remco Treffkorn wrote:
> On Friday 11 July 2003 01:37, Ethan Benson wrote:
> > On Thu, Jul 10, 2003 at 04:59:39PM -0700, Remco Treffkorn wrote:
> > > Ethan,
> > >
> > > The good news is that I now know a little more about powerpc assembly.
> > > The bad news is that the problem was not in the varargs implementation,
> > > but its use.
> > >
> > > You used to call vsnprintf twice.  Once to find out how much buffer would
> > > be needed, then the second time for real. You can't do that without
> > > reseting ap.
> >
> > ah right, i fixed this issue in vasprintf() some time ago.
> 
> I rsynced the tree yesterday. It was not fixed there. Today I see a va_copy 

vasprintf was fixed ages ago:

2002-12-26 04:43:48 GMT Ethan Benson <erbenson@alaska.net> patch-21

    Summary:
      Fix vasprintf and vsscanf, more blacklisting
    Revision:
      prom-libc--devel--1.0--patch-21

    * vasprintf.c: use __va_copy() to allow two uses of the va_list.
      - eventually should use va_copy() instead, but that is only
        available with gcc 3.
...

vfprintf i just fixed last night.  see the commit messages from
yesterday.  (once you see a commit message the mirrors and rsync are
already updated).

> for ap. When did you fix it? There is really no point in me spending a few 
> hours on debugging stuff that you fixed some time ago.

i fixed vAsprintf, ages ago, not vFprintf.

> Ok, that puts it into perspective. At least I know what has not been tested.
> BTW: I rsynced today again. Am I now looking at the current stuff, or am I 
> still working on old code?

check ChangeLog, the current patchlevel is patch-38.

you can monitor this by looking at the ChangeLog fragments posted in
the commit messages (Changes to erbenson....)  the ChangeLog is
automatically maintained by tla for me.

> 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).

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.

-- 
Ethan Benson
http://www.alaska.net/~erbenson/

Attachment: pgp00024.pgp
Description: PGP signature