Reliability of newlib

[Jeff Johnston]

Joel Sherrill wrote:
> Aaron J. Grier wrote:
>> On Wed, Aug 08, 2007 at 04:22:09PM +0200, Petkovic - Ilic, M. wrote:
>>  
>>> I have to determine the reliability of newlib based on the 
>>> experience of
>>> its users. So has anyone found bugs or other problems in newlib and 
>>> if so how
>>> severe were they.  
>>> I would be very grateful if you would provide me with such an
>>> information.     
>>
>> we have been shipping a product with newlib 1.12.0 for almost four
>> years, and have run into the following:
>>
>> 1) a version of snprintf previous to 1.12.0 printed size count
>>    characters instead of size-1, leading to shortened/missing strings
>>    when this was fixed.
>>
>> 2) there is still a memory leak somewhere in _vfprintf_r and points 
>> down    dealing with floating point string rendering where _Balloc is 
>> being
>>    called, but is not properly being freed when libc is shut down via
>>    _reclaim_reent.  the easy workaround has been to avoid doing floating
>>    point printfs in transient threads.
>>
>>   
> This may be related to an open RTEMS PR where the RTEMS
> thread delete newlib extension has to do somethings on its
> own because there wasn't an obvious cleanup routine to call
> in newlib that seemed to fit the bill.
>
> This may be ignorance on our part or it may not have existed
> at the time the port was done.  It is also possible that there
> is a conflict of mutexes since the delete thread extension is
> run from inside RTEMS and you may have to start flushing
> IO on another thread.  I honestly don't remember all the possibilities
> and rationale.
>
> Jeff .. what is the recommended cleanup routine to call on
> the reent structure when a thread is deleted?
>
_reclaim_reent found in libc/reent/reent.c
>
> --joel
>> neither of these were showstoppers for my application.
>>
>>   
>