Standardize the multiple-include protect.
[kopensolaris-gnu/glibc.git] / PROJECTS
index 4c755ff..f4cadfd 100644 (file)
--- a/PROJECTS
+++ b/PROJECTS
@@ -1,6 +1,6 @@
 Open jobs for finishing GNU libc:
 ---------------------------------
-Status: June 1996
+Status: April 1997
 
 If you have time and talent to take over any of the jobs below please
 contact <bug-glibc@prep.ai.mit.edu>
@@ -10,6 +10,8 @@ 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
@@ -17,7 +19,16 @@ contact <bug-glibc@prep.ai.mit.edu>
      standards if they do not contradict each other.
 
 
-[ 3] Write translations for the GNU libc message for the so far
+[ 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.
 
@@ -26,47 +37,35 @@ contact <bug-glibc@prep.ai.mit.edu>
      for the current status (of course better use a mirror of prep).
 
 
-[ 4] Write wordexp() function; this is described in POSIX.2, The
+[ 5] Write wordexp() function; this is described in POSIX.2, the
      header <wordexp.h> already exists.
 
      Implementation idea: use some functions from bash.
 
+**** Somebody is working on this.  Help may or may not be appreciated.
 
-[ 5] Write reentrent versions of crypt() et.al.
-
-     Implementation idea: Define in <crypt.h>
-
-       struct crypt_data
-       {
-         <... all the needed data ...>
-       };
 
-     and define additional functions
-
-       char *crypt_r (__const char *__key, __const char *__salt,
-                      struct crypt_data *__data);
-
-       void setkey_r (__const char *__key, struct crypt_data *__data);
+[ 6] Write `long double' versions of the math functions.  This should be
+     done in collaboration with the NetBSD and FreeBSD people.
 
-       void encrypt_r (char *__block, int __edflag,
-                       struct crypt_data *__data);
+     The libm is in fact fdlibm (not the same as in Linux libc).
 
-     If possible the non-reentrent functions should use the reentrent
-     ones.
+**** Partly done.  But we need someone with numerical experiences for
+     the rest.
 
-     Because of the US export restrictions it might be a good idea if
-     some non-american person does this job.
 
+[ 7] Several math functions have to be written:
 
-[ 6] Write `long double' versions of the math functions.  This should be
-     done in collaboration with the NetBSD and FreeBSD people.
+     - exp2
 
-     The libm is in fact fdlibm (not the same as in Linux libc).
+     each with float, double, and long double arguments.
 
-**** Partly done.
+     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.
 
 
-[ 7] If you enjoy assembler programming (as I do --drepper :-) you might
+[ 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.
 
@@ -76,40 +75,43 @@ contact <bug-glibc@prep.ai.mit.edu>
        Henry Spencer, University of Toronto
        Usenix Winter '92, pp. 419--428
 
-     or just ask.  Currently mostly i?86 optimized versions exist.
+     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 planed to do a complete rewrite.
 
-[ 8] Write nftw() function.  Perhaps it might be good to reimplement the
-     ftw() function as well to share most of the code.
 
-**** Almost done!
+[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.
 
 
-[ 9] Write AVL-tree based tsearch() et.al. functions.  Currently only
-     a very simple algorithm is used.
-     There is a public domain version but using this would cause problems
-     with the assignment.
+[13] Several more or less small functions have to be written:
 
-[10] Extend regex and/or rx to work with wide characters.
+     + tcgetid() and waitid()                  from XPG4.2
+     + grantpt(), ptsname(), unlockpt()                from XPG4.2
 
+     More information is available on request.
 
-[11] Add mmap() support to malloc().
-     Doug Lea's malloc implementation might give some ideas.  Perhaps
-     switching completly to his implementation is an option if it
-     a) can work without mmap() support (not all system GNU libc
-       is running on have mmap)
-     b) is without mmap support at least as fast as the current
-       implementation
-     c) will be extended with the current hooks and additional functions
 
+[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.
 
-[12] Implement shadow password handling.  There exist some but I don't
-     know of any falling under LGPL and where the author is willing to
-     contribute it to the FSF.
 
+[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
 
-[13] Write access function for ether, shadow, netmasks, bootparams,
-     netgroup, publickey, automount, aliases 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.
+               int foo __P ((int, int, int, int));
+
+     Blargh!