This is the mail archive of the
ecos-discuss@sourceware.cygnus.com
mailing list for the eCos project.
Re: Re: vfnprintf and floating point.
Bart,
I'm aware of this statement in C standard. That's why I tried to pass
'va_list*', not 'va_list' to the cvt(). Unfortunately in PowerPC
va_list declared like 'typedef _tag struct {...} va_list[1];'. This
causes troubles. Consider:
typedef int Type[1];
void boo(Type* ptype);
void foo(Type t)
{
boo(&t); // Trouble here: &t has type 'T**', and 'boo' needs
// type 'int (*)[1]'.
}
Just now I don't see how to avoid this.
Regards,
Sergei.
Bart Veer <bartv@cygnus.co.uk> writes:
> >>>>> "Sergei" == Sergei Organov <osv@Javad.RU> writes:
>
> >> > If you interested, I just changed first argument of 'cvt' from
> >> > 'double' to 'va_list*', and moved double argument extraction to this
> >> > routine. I also provided 'void skip_double(va_list*)' that is used to
> >> > skip double argument when floating point support is disabled in
> >> > 'vfnprintf'.
> >>
> >> Since you've already done it, if you send me the patch (use `cvs diff -u5')
> >> then I'll put it in. You are working from the anonymous CVS version,
> >> yes?
>
> Sergei> Yes, I use anonymous CVS version. But I just found that my
> Sergei> initial solution while works for i386 causes troubles for
> Sergei> PowerPC because of different definition of 'va_list'. If
> Sergei> and when I find solution, I'll send patch to you.
>
> I have just had a look at my copy of the ANSI C standard. It contains
> the following statement (where ap is a va_list):
>
> "The object ap may be passed as an argument to another function: if
> that function invokes the va_arg macro with parameter ap, the value of
> ap in the calling function is indeterminate and shall be passed to the
> va_end macro prior to any further reference to ap."
>
> I think this means that passing a va_list to another function such as
> cvt() which performs partial processing, and then continuing to use
> the va_list in the current printf() function, is not allowed. The
> description of e.g. vfprintf() appears to confirm this. It may work
> with some architectures, but there are no guarantees. It is possible
> that the gcc team would be willing to provide stronger guarantees than
> provided by the standard, but since there already appear to be
> problems with the PowerPC this seems unlikely.
>
> Bart Veer // eCos net maintainer