"Larry Barello" <[EMAIL PROTECTED]> 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. ;-) _______________________________________________ AVR-GCC-list mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/avr-gcc-list
