mirror of
https://sourceware.org/git/glibc.git
synced 2024-11-27 11:43:34 +08:00
acaee4d7aa
1998-01-31 00:21 Ulrich Drepper <drepper@cygnus.com> * posix/regex.c: Add some more cleanups by Akim Demaille. 1998-01-30 23:55 Ulrich Drepper <drepper@cygnus.com> * signal/signal.h: Revert last change. * string/strsignal.c: Regard signal number NSGI as illegal. * sysdeps/unix/sysv/linux/siglist.c: Define array only with NSIG members.
104 lines
3.6 KiB
Plaintext
104 lines
3.6 KiB
Plaintext
Open jobs for finishing GNU libc:
|
||
---------------------------------
|
||
Status: January 1998
|
||
|
||
If you have time and talent to take over any of the jobs below please
|
||
contact <bug-glibc@prep.ai.mit.edu>
|
||
|
||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||
|
||
[ 1] Port to new platforms or test current version on formerly supported
|
||
platforms.
|
||
|
||
**** See http://www.gnu.org/software/libc/porting.html for more details.
|
||
|
||
|
||
[ 2] Test compliance with standards. If you have access to recent
|
||
standards (IEEE, ISO, ANSI, X/Open, ...) and/or test suites you
|
||
could do some checks as the goal is to be compliant with all
|
||
standards if they do not contradict each other.
|
||
|
||
|
||
[ 3] The IMHO opinion most important task is to write a more complete
|
||
test suite. We cannot get too many people working on this. It is
|
||
not difficult to write a test, find a definition of the function
|
||
which I normally can provide, if necessary, and start writing tests
|
||
to test for compliance. Beside this, take a look at the sources
|
||
and write tests which in total test as many paths of execution as
|
||
possible.
|
||
|
||
|
||
[ 4] Write translations for the GNU libc message for the so far
|
||
unsupported languages. GNU libc is fully internationalized and
|
||
users can immediately benefit from this.
|
||
|
||
Take a look at the matrix in
|
||
ftp://prep.ai.mit.edu/pub/gnu/ABOUT-NLS
|
||
for the current status (of course better use a mirror of prep).
|
||
|
||
|
||
[ 6] Write `long double' versions of the math functions. This should be
|
||
done in collaboration with the NetBSD and FreeBSD people.
|
||
|
||
The libm is in fact fdlibm (not the same as in Linux libc).
|
||
|
||
**** Partly done. But we need someone with numerical experiences for
|
||
the rest.
|
||
|
||
|
||
[ 7] Several math functions have to be written:
|
||
|
||
- exp2
|
||
|
||
each with float, double, and long double arguments.
|
||
|
||
Beside this most of the complex math functions which are new in
|
||
ISO C 9X should be improved. Writing some of them in assembler is
|
||
useful to exploit the parallelism which often is available.
|
||
|
||
|
||
[ 8] If you enjoy assembler programming (as I do --drepper :-) you might
|
||
be interested in writing optimized versions for some functions.
|
||
Especially the string handling functions can be optimized a lot.
|
||
|
||
Take a look at
|
||
|
||
Faster String Functions
|
||
Henry Spencer, University of Toronto
|
||
Usenix Winter '92, pp. 419--428
|
||
|
||
or just ask. Currently mostly i?86 and Alpha optimized versions
|
||
exist. Please ask before working on this to avoid duplicate
|
||
work.
|
||
|
||
|
||
[10] Extend regex and/or rx to work with wide characters and complete
|
||
implementation of character class and collation class handling.
|
||
|
||
It is planned to do a complete rewrite.
|
||
|
||
|
||
[11] Write access function for netmasks, bootparams, and automount
|
||
databases for nss_files and nss_db module.
|
||
The functions should be embedded in the nss scheme. This is not
|
||
hard and not all services must be supported at once.
|
||
|
||
|
||
[14] We need to write a library for on-the-fly transformation of streams
|
||
of text. In fact, this would be a recode-library (you know, GNU recode).
|
||
This is needed in several places in the GNU libc and I already have
|
||
rather concrete plans but so far no possibility to start this.
|
||
|
||
*** The library is available, now it remains to be used in the streams.
|
||
|
||
|
||
[15] Cleaning up the header files. Ideally, each header style should
|
||
follow the "good examples". Each variable and function should have
|
||
a short description of the function and its parameters. The prototypes
|
||
should always contain variable names which can help to identify their
|
||
meaning; better than
|
||
|
||
int foo __P ((int, int, int, int));
|
||
|
||
Blargh!
|