Re: [avr-gcc-list] stdio - how extensible?

[Joerg Wunsch]

"Larry Barello" <address@hidden> wrote:

> Well, duh, it didn't work since the second call to
> fdevopen() (task 2) failed miserably.

Can you explain `failed miserably' in some more technically
descriptive phrase?

> So, the question is: what would it take to extend the current stdio
> facility to allow N descriptors (rather than just stdout, stdin and
> stderr).

Nothing: it's supposed to be possible already.  It's only that stdin,
stdout, and stderr are pre-defined names identifying slots 0 through 2
in the (fixed-size) table named __iob[] as the C standard basically
requires these names, and programmers are very accustomed to use them.

But other than that, fdevopen() returns a FILE * just as fopen() does
in any hosted implementation.  If you use the old API, make sure you
call fclose() if you don't need the file handles anymore, to free the
space.  (That reminds me: I need to make sure in the new API that
nobody could call fclose() on such a handle...)

> A second question: is stdio written to be re-entrant?

Currently not, as malloc() is used, and that's not re-entrant anyway.
Also, the floating-point routines use a malloc()ed buffer, but well,
that one's actually a local variable, so it might be reentrant.

But have a look at the new API for the upcoming avr-libc-1.4.  See the
avr-libc-dev discussion recently (Cc'ed here).

I just updated the doc snapshot at

http://uriah.heep.sax.de/avr-libc/

once again.  Btw., you are invited to have a look at any reentrancy
issues, and review the code for that.  While reentrancy is not the
primary goal of avr-libc, if we can improve something in that area,
we're certainly willing to do so.

-- 
cheers, J"org               .-.-.   --... ...--   -.. .  DL8DTL

http://www.sax.de/~joerg/                        NIC: JW11-RIPE
Never trust an operating system you don't have sources for. ;-)