Re: AW: [avr-gcc-list] reentrant interrupt service routine

[Mark Litwack]

Ok, so there's at least one more for the non-reentrant list
that I've discovered:

   printf (and friends)

Printf returns a character count which is stored in a FILE
structure.  If you're using a global FILE for stdout with
printf()'s in multiple threads, the count may be incorrect.
Most code doesn't check character count returned from
printf, so it's usually not a problem.

But there's also a surprise issue if you're using printf_P()
and similar functions.  printf_P() changes a flag value in
the FILE structure while getting the format string out of
program memory and then restores the flag when it's done.
If this overlaps with another printf(), garbage can result
(and I mean besides the interspersed characters from both
printf()'s).

A successful workaround for this seems to be to give each
thread its own FILE structures to work on, assuming you've
got thread safe character IO at the lower level.

As a side note sprintf(), doesn't appear to have this problem
since it creates its own temporary FILE structure on the
stack.

I don't mean to carry on a conversation with myself, so if
no one else is interested in reentrant/non-reentrant I'll be
quiet now, but I would appreciate any other non-reentrant
issues that people know about.  It's hard to find these
things when they happen.
  
-mark


On Wednesday 02 April 2008 06:19:51 pm Mark Litwack wrote:
> So this begs the question... What *isn't* re-entrant?
>
> The avr-libc docs mention:
>
>    strtok()    re-entrant version: strtok_r()
>    rand()      re-entrant version: rand_r()
>    random()    re-entrant version: random_r()
>    eeprom_*()  uses IO registers
>    strtod()    uses errno
>    strtol()    uses errno
>    strtoul()   uses errno
>
> Is there anything else lurking that wouldn't be re-entrant
> using avr-libc 1.6.1 and gcc >=4.2?
>
> Thanks,
>
> -mark
>
> On Wednesday 02 April 2008 05:40:22 pm Dmitry K. wrote:
> > On Wednesday 02 April 2008 15:33, Pink Boy wrote:
> > [...]
> >
> > > And for a number for compilers I've dealt with, floating point
> > > operations were not reentrant safe and in one case long division
> > > wasn't safe either.
> >
> > Avr-gcc's division, multiplication are reentrant.
> > Avr-libc's float point operations are reentrant.
> > Avr-libc 1.6 math functions are reentrant: the errno
> > variable is not changed (modern C standart permits this).
> >
> > Regards,
> > Dmitry.
> >
> >
> >
> > _______________________________________________
> > AVR-GCC-list mailing list
> > address@hidden
> > http://lists.nongnu.org/mailman/listinfo/avr-gcc-list