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

[Bernard Fouché]

I just don't see why hiding inner workings of FILE requires a
stdio_private.h file: micro-controler programs are usually designed by
people used to face technical details and the paradox here is to bring
calloc/malloc in the game only to offer something that looks clean, but is
not.

BTW I don't think that fdevopen is a standard libc function so having a
different way to bring in avrlibc in a project than to go thru fdevopen
would not be a nightmare.

IMHO I would prefer to include <stdio.h> and have this file the same for the
internals of avr-libc and the external interface. Also, __iob[] should not
be defined in fdevopen but let as 'extern'. Using avr-libc would require the
user to explicitely define memory allocation for __iob[], for instance by
doing:

FILE stdout,stdin,stderr;

and the user would do so only if streams descriptors with these names are
required and puts/putchar/printf used. Otherwise he would use the names he
wants and use only fprintf/fputs/etc.

-----Message d'origine-----
De : Svein E. Seldal [mailto:address@hidden
Envoyé : mercredi 8 septembre 2004 10:38
À : Bernard Fouché
Cc : address@hidden
Objet : Re: [avr-libc-dev] being able to use libc without fdevopen?


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