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

[Bernard Fouché]

Joerg Wunsch wrote:

> As the malloc()-less API change is long overdue, I'd rather move that
> in by the same time.  We're going to have a new library minor version
> number, so we are eligible for an API change anyway.
>  
Great!

> How about the following API:
>
> #define __STDIO_FBUF_SIZE (sizeof(struct __file))
> #define __STDIO_FPBUF_SIZE 40
>
> FILE *fdevopen(int(*put)(char, FILE *), int(*get)(FILE *),
>               void *fbuf, void *fpbuf);
> < ..api proposal..>
>
> Does that sound as a useful compromise to anybody?
>
>  
Yes, now what about being able to use it also with cpp only if needed?

IMHO most, if not nearly all, embedded applications will setup
stdin/out/err as soon as the code starts and never reconfigure them
again later.

So each application will make a few calls to fdevopen() to setup the
memory in a particular state, this state being the same one each time
the application starts. My opinion is that if we could reach the
final memory state that we want by using macros instead of compiled
code, we may have something that is easy to configure and has no side
effect with malloc/free and that will not use unneeded code bytes:
__do_copy_data() will do the job for us.

So if we can have something like (using the current l__file):

->in stdio.h:
#define STDIO_SETUP(stream,buf,put,get,flags) FILE stream={buf,\
                   0,\
                   flags,\
                   sizeof(buf),\
                   0,\
                   put,\
                   get}



->when we need to define a stream:

uint8_t mybuf[32];
int myput(char);
int myget(void);

STDIO_SETUP(stdout,mybuf,myput,myget,__SWR);

Then it's just a problem of documentation and eventually renaming
flags like __SRW if one wants something more explicit.

(Also the macro uses 'sizeof(buf)' which maybe a bad idea.)

A C function like fdevopen() can still be provided so if ever one
needs to reconfigure the ios at some time (or wants to drop
__do_copy_data :-)), it would be still possible.

 Bernard