As Alexey Boyko wrote:
> I found, that printf_P (and other xxprintf_P) is not reenterable.
> (I am using some sort of thread switching library)
Yes, agreed. We don't pretend it were:
``General information about this library
...
Unless otherwise noted, functions of this library are not guarenteed
to be reentrant. In particular, any functions that store local state
are known to be non-reentrant, as well as functions that manipulate IO
registers like the EEPROM access routines. If these functions are used
within both, standard and interrupt context, undefined behaviour will
result.''
OK, you might file a (documentation) bug report so the stdio _P
function will also explicitly mentioned there.
> I've solve this by adding this function body in program:
> int printf_P(const char *fmt, ...)
> {
> va_list ap;
> int i;
>
> va_start(ap, fmt);
> //stdout->flags |= __SPGM;
> i = vfprintf(stdout, fmt, ap);
> //stdout->flags &= ~__SPGM;
But of course, that's not a generally applicable solution.
The only solution I could quickly imagine of is to not use vfprintf()
as the central backend function but something like
__vfprintf_internal() that gets an additional argument to tell about
whether the format string is in RAM or ROM. Then, all the wrapper
functions would have to be rewritten to accomodate for the new
interface.
Same applies to the scanf() family.
If someone was willing to provide a patch for that, I wouldn't mind.
Otherwise, it's got a low priority on my list of things to do.
--
cheers, J"org .-.-. --... ...-- -.. . DL8DTL
http://www.sax.de/~joerg/ NIC: JW11-RIPE
Never trust an operating system you don't have sources for. ;-)
_______________________________________________
AVR-libc-dev mailing list
[email protected]
http://lists.nongnu.org/mailman/listinfo/avr-libc-dev
