[uClibc] Functions listed by SuSv3 but not (yet) included in uClibc

Manuel Novoa III mjn3 at codepoet.org
Mon Mar 8 22:16:59 UTC 2004


Hello,

On Mon, Mar 08, 2004 at 10:56:09PM +0100, Alexander van Heukelum wrote:
> Hi Erik, Manuel,
> 
> [snip](including "audit the headers" part)[/snip]
> 
> > > ndbm.h: [all=9] dbm_*
> > You can use gdbm.
> 
> Ok, but they are still missing from uClibc.

Nor are they in glibc.

> > > string.h: strerror_r
> > There is a complication with strerror_r.  The glibc extension function
> > of the same name has a diffferent prototype and behavior.  See the
> > comments in string.h.  The current workaround is to redirect strerror_r
> > to either _susv3_strerror_r or _glibc_strerror_r, depending on the
> > feature test macros.
> 
> Hmm, if I understand it right this problem can also be solved by having
> a susv3-compatible strerror_r with it's proper name, and, in case
> compatiblity with glibc is required, define a macro strerror_r that
> redirects to _glibc_strerror_r.

This was an interim solution until I see which way glibc jumps.  From
a practical point of view, we need to worry about a certain level of
source compatibility.  The way I set things up is guaranteed to cause
a build problem (i.e. raise a flag) for applications that try to use
strerror_r without including the appropriate header.

> > > setjmp.h: setsigjmp
> > Only visible with the appropriate feature test macros.  See setjmp.h
> > and the (conditional)
> >  # define sigsetjmp(env, savemask) __sigsetjmp (env, savemask)
> 
> Does susv3 allow this? Why? (read: I don't like this! ;) )

>From the Rational section...

The ISO C standard specifies various restrictions on the usage of the
setjmp() macro in order to permit implementors to recognize the name in
the compiler and not implement an actual function. These same
restrictions apply to the sigsetjmp() macro.

So sigsetjmp isn't guaranteed to be a function.

> > > monetary.h: strfmon
> > Ugh... I've looked at strfmon.  Does anyone actually use it?
> 
> I don't think so, but it is in the Standard...

Yes it is.  But until I actually find a need for it, I don't plan to
implement it unless contracted to do so.  Even porting the glibc
implementation isn't really an option.  I looked at it a while back
and the code is huge.  :-(

> > Would you mind emailing me your complete list?
> 
> I also cleaned up the scripts and attached them. Cleaning up scripts
> helped to spot a few errors... I omitted all symbols from time.h and
> ucontext.h, there were two false positives (mktemp and mkstemp), and the
> interface strerror_r has been moved to optional interfaces, because it
> depends on TSF. Oh, and I missed 20 mathematical interfaces...
> 
> The result (which I believe is correct): mandatory interfaces: 40,
> optional interfaces: 144 and mathematical interfaces: 203.

Great!  Thanks!

Manuel



More information about the uClibc mailing list