[avr-libc-dev] [bug #23128] Non-reentrant library calls should be made reentrant

[Mark Litwack]

URL:
  <http://savannah.nongnu.org/bugs/?23128>

                 Summary: Non-reentrant library calls should be made
reentrant
                 Project: AVR C Runtime Library
            Submitted by: mlitwack
            Submitted on: Thursday 05/01/2008 at 14:45
                Category: Feature Request
                Severity: 3 - Normal
                Priority: 5 - Normal
              Item Group: libc code
                  Status: None
        Percent Complete: 0%
             Assigned to: None
             Open/Closed: Open
         Discussion Lock: Any
                 Release: 1.6.1
           Fixed Release: None

    _______________________________________________________

Details:

The avr-libc FAQ has a more detailed discussion on
non-reentrant library calls.  (See patch #6500 if the
reentrant update to the FAQ has not yet been applied.)

This bug has been opened as a placeholder for those calls
which could be made reentrant.  It is low priority since
reasonable workarounds exist.

Short duration calls and macros that appear in the FAQ that
can easily be reentrant with a cli()/sei() or ATOMIC_BLOCK()
are not included in this bug.

------------------------------------------------------------

Calls:        strtod(), strtol(), strtoul()

Issue:        They all use the global "errno".  Errno
              could be returned wrong.

Possible fix: Create *_r versions, similar to strtok_r(),
              where the error status is returned via a
              passed pointer to an int or uint8_t.

------------------------------------------------------------

Calls:        printf(), vprintf(), puts()

Issue:        stdout is global and these calls alter a
              character counter in stdout's FILE struct via
              vfprintf().  Returned character count could be
              wrong.

Possible fix: Instead of changing values in stdout, perhaps
              introduce another call layer like
              vfprintf_r(), so that character count can be
              kept on the stack.

------------------------------------------------------------


Calls:        printf_P(), vprintf_P(), puts_P()

Issue:        stdout is global and in addition to the
              character count issue above, these calls also
              alter a flag in stdout to make vfprintf()
              read format strings from PGM space.

Possible fix: Similar to above.  A call layer to keep the
              keep the flag values on the stack could work.

------------------------------------------------------------

Calls:        fprintf(), fprintf_P(), vfprintf(),
              vfprintf_P(), fputs(), fputs_P()

Issue:        The same problems exist as with stdout above
              when using a global FILE with these calls.

Possible fix: Same as printf().

------------------------------------------------------------

Calls:        assert()

Issue:        Uses fprintf().

Possible fix: Fixed when fprintf() is fixed.

------------------------------------------------------------

Calls:        getchar(), gets()

Issue:        stdin is global and these calls alter flags,
              character count, and the unget buffer in
              stdin's FILE struct.

Possible fix: None?  Needs locking because unget buffer is
              persistent between calls and locking is
              implementation dependent.  Could create *_r
              versions and have a non-global unget but it
              may not be worth the trouble.

------------------------------------------------------------

Calls:        fgetc(), ungetc(), fgets(), scanf(),
              scanf_P(), fscanf(), fscanf_P(), vscanf(),
              vfscanf(), vfscanf_P(), fread()

Issue:        The same problems exist as with stdin above
              when using a global FILE with these calls.

Possible fix: None?  See above for getchar().

------------------------------------------------------------





    _______________________________________________________

Reply to this item at:

  <http://savannah.nongnu.org/bugs/?23128>

_______________________________________________
  Message sent via/by Savannah
  http://savannah.nongnu.org/