RE: [avr-gcc-list] fdevopen() uses calloc?

[Dave Hylands]

One a slightly different vein, here's a printf like function that you
can easily redirect the output anywhere:
http://www.efgh.com/software/gprintf.htm

It becomes very easy to write lcd_printf, or uart_printf, or any other
type of output.

This particular implementation doesn't require any external memory
allocations.

--
Dave Hylands
Vancouver, BC, Canada
http://www.DaveHylands.com/

> -----Original Message-----
> From: J.C. Wren [mailto:address@hidden 
> Sent: Tuesday, January 20, 2004 11:04 PM
> To: address@hidden
> Subject: [avr-gcc-list] fdevopen() uses calloc?
> 
> 
> fdevopen() is using calloc(), which pulls in a lot of extra code.  Is 
> there any reason this couldn't use a static, instead? 
> 
> I wrote my own fdevopen function (slightly different name), but the 
> linker is still pulling in fdevopen(), even though I can find no 
> references to it.  Why would this be?  If I name my function 
> fdevopen(), 
> the linker gets all whiney about the size changing between my .o file 
> and the libc file. 
> 
> To write mine, I had to cheat and copy over stdio_private.h, 
> which is a 
> major hack.  What I'd like is an fdevopen() variant that 
> allows passing 
> a user provided block of memory.  Unfortunately, this has to 
> be of size 
> FILE, which is opaque, so we don't know how large a block of 
> memory to 
> declare. 
> 
> In lieu of fdevopen() using a static buffer, can fdevopen() be a weak 
> reference so at least overriding it doesn't cause the 
> compiler to get upset?
> 
>     --jc
> 
> _______________________________________________
> avr-gcc-list mailing list
> address@hidden 
> http://www.avr1.org/mailman/listinfo/avr-gcc-> list
> 
>