Re: [avr-libc-dev] being able to use libc without fdevopen?

[Frederik Rouleau]

Like many people I had the same pb. I have then chosen an other way than 
Svein.
I had statically allocated files streams in fdevopen.
So fdevopen became :

FILE stdStream[MAXSTREAM];
static unsigned char CurrentStream = 0;

//....

   //    if ((s = calloc(1, sizeof(FILE))) == 0)
   if ((CurrentStream >= MAXSTREAM)||((s = &stdStream[CurrentStream++]) 
== 0))

The pb with that is that the number of stream is fixed in the lib( 
MAXSTREAM).

Svein's proposal seems better to me. I am wondering what are the 
benefits of hiding FILE's structure ? Otherwise Svein's pb of FILE's 
structure size will be solved....


Svein E. Seldal wrote:

> Bernard Fouché wrote:
>
> > Hi.
> >
> > I'm using an atmega162 and being short on flash. So I removed fdevopen
> > because I use only printf/puts, etc, with no float. fdevopen bring in
> > calloc/malloc and that eats more than one K of flash + ram overhead for
> > dynamic allocation. I was not able to link without the official 
> > fdevopen,
> > maybe I misunderstood linker options like "-Wl,-u,fdevopen".
> >
> > To get rid of calloc/malloc in my application, I had to get rid of 
> > fdevopen
> > and to do so include stdio_private.h in my code and regenerate a libc
> > without fdevopen.
> >
> > Is there another way to do it (I'd like to keep using the libc the
> > 'official' way) ?
>
>
> I have been annoied by the same fact. In fact I do not want to use the 
> official avr-libc printf because it eats too much resources. After a 
> brief investigation it turns out to be the addition of the fdevopen, 
> which in turn pulls in calloc.  Since I'm using a very small AVR, I 
> absolutely do not want to use calloc. Hence avr-libc printf was dropped.
>
> The reason that is so cumbersome today is basically because the 
> developers dont want to reveal the size of FILE/struct __file. They 
> have a avr-libc build-time implementation which is hidden from the 
> user. E.g. to take sizeof(FILE) in an application is impossible 
> because struct __file has no implementation in stdio.h. When you call 
> fdevopen you will be returned a pointer to a memoryarea (of unknown 
> size) to a struct __file. This unknown size is the size of the FILE 
> implementation in the internal parts of the libc library.
>
> While the idea to do this hiding of FILE's implementation is good, I 
> dont like it when being used on a small microcontroller, because it 
> requires calloc/malloc to work.
>
> So my request is basically the same as Bernards request: Can we please 
> make a static implementation of FILE, so that we dont need to have 
> calloc to make it work. Or to put it in another way: I dont want to 
> implement calloc _only_ because printf requires it.
>
> I have an outline to fix this. It might not be the best solution, but 
> it can possibly help to find a working version that does not require 
> calloc.
>
>
> in stdio.h:
>
> #define FILE_SIZEOF 8
> typedef uint8_t FILE[FILE_SIZEOF];
>
>
> in stdio_private.h:
>
> struct __file {
>     ...
> }
>
> in fdevopen.c:
>
> FILE *
> fdevopen_static(FILE *file, int (*put)(char), int (*get)(void), int 
> opts __attribute__((unused)))
> {
>     struct __file *s = (struct __file *)file;
> }
>
> in app.c:
>
> int main(void)
> {
>     FILE static_file;
>     fdevopen_static(&file,my_putc,my_getc,0);
> }
>
>
> The first assumption is that FILE is not defined to be struct __file.
>
> The biggest challenge here is to keep sizeof(struct __file) == 
> sizof(FILE) in sync. Maybe the FILE_SIZEOF could be autogenererated 
> when the struct __file is compiled in the libc function?
>
>
> Svein
>
>
> _______________________________________________
> AVR-libc-dev mailing list
> address@hidden
> http://lists.nongnu.org/mailman/listinfo/avr-libc-dev