reentrant functions

Robin Getz rgetz at
Tue Jun 10 05:23:21 UTC 2008

On Sun 8 Jun 2008 11:35, Denys Vlasenko pondered:
> On Sunday 08 June 2008 16:21, Bernd Schmidt wrote:
> > Denys Vlasenko wrote:
> > > Ok, this is a scenario: the user runs a "passwd" utility on NOMMU
> > > box. This utility has 20k of text and 80k of data. 70k of this data
> > > is occupied by des.c static buffer.
> > > 
> > > At this moment the machine has only 90k RAM available, has no swap
> > > etc. It cannot satisfy load request for this application.
> > > So user gets some error message from the shell to this effect.
> > > 
> > > If des.c buffer is not static but is __uc_malloc'ed, program will
> > > load succesfully, and then __uc_malloc will fail and exit
> > > with "no memory!" message.
> > > 
> > > In both cases user's experience is essentially the same - [s]he
> > > cannot run the program because there is not enough memory.
> > 
> > Except the program that called crypt may have left some state - 
> > temporary files, partial modifications in other files, whatever - 
> > because it did not expect to fail at this point.
> If this program wants to not be killed by OOM, it needs to install
> the handler for this situation. It is not difficult at all.

The question is not how difficult it is or not.
==== snip =====
 nearly all applications supported by glibc also work perfectly with uClibc. 
Porting applications from glibc to uClibc typically involves just recompiling 
the source code.
==== snip =====

If you are talking about deviating from the "just recompiling" mantra - even 
to handle corner case error conditions, I need to rethink using uClibc going 

The expectation is functionality as specified in IEEE Std 1003.1 

It seems like more and more functions that you are modifying are deviating 
from the standard, defined interface. I always thought the project goals 
 1) standard functionality
 2) minimum size 

Have things changed so it is the other order? Changing the project goals is 
something I would not support.

More information about the uClibc mailing list