[ECOS] vfnprintf and floating point.

[ECOS] vfnprintf and floating point.

[Sergei Organov]

Hello,

I just tried to separate floating point code from 'vfnprintf'
routine. It was surprisingly easy to do, but I remember that it didn't 
seem so easy for similar code found in 'newlib'. The code found in
eCos libc is much better organized, but it seems that "Inf" and "NaN"
processing was removed from the code entirely. What's the reason?

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

Sergei.

Re: [ECOS] vfnprintf and floating point.

[Jonathan Larmour]

Sergei Organov wrote:
> 
 
> I just tried to separate floating point code from 'vfnprintf'
> routine. It was surprisingly easy to do, but I remember that it didn't
> seem so easy for similar code found in 'newlib'. The code found in
> eCos libc is much better organized, but it seems that "Inf" and "NaN"
> processing was removed from the code entirely. What's the reason?

newlib uses the "mprec" library, which is more precise but substantially
larger. I decided to avoid it because of the extra restrictions imposed on
embedded systems. However, I do want to add configurability to this in
future so people can choose the implementation they want. It's just not
there right now.
 
> 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? 

Jifl
-- 
Cygnus Solutions, 35 Cambridge Place, Cambridge, UK.  Tel: +44 (1223) 728762
"I used to have an open mind but || Get yer free open source RTOS's here...
 my brains kept falling out."    || http://sourceware.cygnus.com/ecos
Help fight spam! http://spam.abuse.net/  These opinions are all my own fault

Re: [ECOS] vfnprintf and floating point.

[Sergei Organov]

Jonathan Larmour <jlarmour@cygnus.co.uk> writes:
> Sergei Organov wrote:
[...]
> > 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?

Yes, I use anonymous CVS version. But I just found that my initial
solution while works for i386 causes troubles for PowerPC because of
different definition of 'va_list'. If and when I find solution, I'll
send patch to you.

Regards,
Sergei.

[ECOS] Re: vfnprintf and floating point.

[Bart Veer]

>>>>> "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

Re: [ECOS] Re: vfnprintf and floating point.

[Sergei Organov]

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

[ECOS] Re: vfnprintf and floating point.

[Bart Veer]

>>>>> "Sergei" == Sergei Organov <osv@Javad.RU> writes:

    Sergei> I'm aware of this statement in C standard. That's why I
    Sergei> tried to pass 'va_list*', not 'va_list' to the cvt().
    Sergei> Unfortunately in PowerPC va_list declared like 'typedef
    Sergei> _tag struct {...} va_list[1];'. This causes troubles.
    Sergei> Consider:

    Sergei> typedef int Type[1];

    Sergei> void boo(Type* ptype);

    Sergei> void foo(Type t)
    Sergei> {
    Sergei>   boo(&t); // Trouble here: &t has type 'T**', and 'boo' needs
    Sergei>            // type  'int (*)[1]'.
    Sergei> }

    Sergei> Just now I don't see how to avoid this.

OK, I have done some more checking. The 1989 standard does not go into
further detail on this, so it is debatable whether or not passing a
va_list via a pointer rather than by value is legal. According to a
draft of the C9x standard it is legal to pass a pointer to a va_list
to another function things should work as you expect. The C++ standard
does not address the issue directly, it just references the C
standard. This is one of the areas that will have to be addressed as
gcc moves to C9x compliance, but it may take a while before anything
happens.

Bart Veer // eCos net maintainer

Re: [ECOS] Re: vfnprintf and floating point.

[Sergei Organov]

Well, it seems gcc indeed needs to be fixed in this area to be C9x
compliant :-) At least I can't find clean way to do what I want with
current gcc :-(

Sergei.

P.S. Actually, '&t' has type 'int**' in the example, not 'T**'.

Bart Veer <bartv@cygnus.co.uk> writes:
> >>>>> "Sergei" == Sergei Organov <osv@Javad.RU> writes:
> 
>     Sergei> I'm aware of this statement in C standard. That's why I
>     Sergei> tried to pass 'va_list*', not 'va_list' to the cvt().
>     Sergei> Unfortunately in PowerPC va_list declared like 'typedef
>     Sergei> _tag struct {...} va_list[1];'. This causes troubles.
>     Sergei> Consider:
> 
>     Sergei> typedef int Type[1];
> 
>     Sergei> void boo(Type* ptype);
> 
>     Sergei> void foo(Type t)
>     Sergei> {
>     Sergei>   boo(&t); // Trouble here: &t has type 'T**', and 'boo' needs
>     Sergei>            // type  'int (*)[1]'.
>     Sergei> }
> 
>     Sergei> Just now I don't see how to avoid this.
> 
> OK, I have done some more checking. The 1989 standard does not go into
> further detail on this, so it is debatable whether or not passing a
> va_list via a pointer rather than by value is legal. According to a
> draft of the C9x standard it is legal to pass a pointer to a va_list
> to another function things should work as you expect. The C++ standard
> does not address the issue directly, it just references the C
> standard. This is one of the areas that will have to be addressed as
> gcc moves to C9x compliance, but it may take a while before anything
> happens.
> 
> Bart Veer // eCos net maintainer