Re: [avr-gcc-list] Re: [avr-libc-dev] Please have a look at avr-libc patch #3750

[Bernard Fouché]

Joerg Wunsch wrote:

> As malloc() was `in' there (from fdevopen()) anyway, it came in handy.
>
> Of course, if there's consensus among the users that this is not
> needed, and an additional 40 bytes on the stack are no big deal for
> the floating-point versions, we could easily drop that completely, and
> always allocate the buffer on the stack.
>  
Looking at malloc compiled code, it seems that malloc.c needs 6 bytes of 
.data (reported by avr-size)
and will use also 2 bytes on the stack when called (two registers 
pushed). So the net loss is only 32 bytes
when the floating point buffer is allocated from the stack. Note also 
that if an application is not able
to get some bytes from malloc() and vfprintf can't produce the expected 
floating output, there are
big chances that it's also an application failure. I would drop the call 
to malloc/free.

> As Björn Haase wrote:
>
>  
>
> > We *are* already having a working alloca. It's within gcc. Only
> > thing that you need is an appropriate function declaration.
> >    
>
> That sounds like a good idea.
>  
Cool!

> I agree there'd better be macros for this, but how to name them?
>
> #define _FDEV_ERR (-1)
> #define _FDEV_EOF (-2)
>
> Sounds OK?
>  
Since they start with '_', no problem

> > In the example code using fdev_setup_stream(), I would put the macro
> > call outside of a body function.
> >    
>
> fdev_setup_stream() works like a function, so it needs to be called
> inside a function body.  But you're right, the initializer macro
> you've been been proposing also has some merit, so I'll add that one,
> too.
>  
its main merit is to save flash space if there is __do_copy_data().

I like all these changes, now what about the other users?

  Bernard