[Top][All Lists]

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

Re: [avr-gcc-list] Re: [avr-libc-dev] Please have a look at avr-libc pat

From: Bernard Fouché
Subject: Re: [avr-gcc-list] Re: [avr-libc-dev] Please have a look at avr-libc patch #3750
Date: Mon, 05 Sep 2005 17:22:19 +0200
User-agent: Mozilla Thunderbird 1.0.2 (Windows/20050317)

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.

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,\

->when we need to define a stream:

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


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.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]