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

[J.C. Wren]

See comments in-line, please.

   --jc

Joerg Wunsch wrote:

> [Please do not followup to unrelated articles.  You've just made two
> articles into an entirely different thread -- see the `References'
> header.]
>  
I have no idea what you're talking about, here.   I don't see any 
'References' section.  Sometimes I create a new thread by replying to an 
old one and changing the subject.  I've also recently switch to Mozilla 
Thunderbird for a mail client, and I despise it's so-called 'Reply All' 
function.  Rarely does it actually fill the To: list with the proper 
list of replyees.

> "J.C. Wren" <address@hidden> wrote:
>
>  
>
> > fdevopen() is using calloc(), which pulls in a lot of extra code.
> > Is there any reason this couldn't use a static, instead?
> >    
>
> It's been on my medium-priority todo list for some time to provide an
> fdevopen() implementation that can handle only stdin/stdout/ stderr,
> but has the struct __file for them pre-defined.
>
> OTOH, it's probably of only limited use.  Anyone who's going to use
> printf() is certainly running a larger device than an ATmega2313 ;-),
> and perhaps is using malloc() already anyway.  Note that while it is
> hard to replace fdevopen() itself in your application, it should be
> trivial to replace malloc() and free() by your own versions.
>  
I use printf() all the time, particularly in debugging, without ever 
using malloc() and free().  I've always avoided malloc() and friends in 
embedded systems, partly because the functions themselves consume a 
moderate amount of space, most requirements for them can be handled as 
easily or better with a static declaration.  Declaring buffers as static 
also causes them to show up the map file, so it's a lot easier to 
determine if you're getting close to the limit on memory or not.

Collectively, malloc(), calloc() and free() use around 1K, which is 
6.25% of the code space on a Mega16.  It also consumes 8 or so bytes of 
SRAM. 

>  
>
> > To write mine, I had to cheat and copy over stdio_private.h, which
> > is a major hack.
> >    
>
> I've seen a number of (ancient) Unix opensource tools that started to
> depend on internals of struct __file, which in turn caused major
> headaches when some system started to implement stdio in a different
> manner.  I simply wanted to avoid this kind of upgrade nightmare, thus
> I made struct __file a private entity.
>  
Agreed, I don't like exposing the internals of FILE either.

> I could provide a #define for the sizeof(struct __file) in <stdio.h>
> if people found that to be useful.
>  
This could be useful.