1: Open jobs for finishing GNU libc:
    2: ---------------------------------
    3: Status: October 2004
    4: 
    5: If you have time and talent to take over any of the jobs below please
    6: contact <bug-glibc@gnu.org>.
    7: 
    8: ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    9: ^L
   10: [ 1] Port to new platforms or test current version on formerly supported
   11:      platforms.
   12: 
   13: **** See http://www.gnu.org/software/libc/porting.html for more details.
   14: 
   15: 
   16: [ 2] Test compliance with standards.  If you have access to recent
   17:      standards (IEEE, ISO, ANSI, X/Open, ...) and/or test suites you
   18:      could do some checks as the goal is to be compliant with all
   19:      standards if they do not contradict each other.
   20: 
   21: 
   22: [ 3] The IMHO opinion most important task is to write a more complete
   23:      test suite.  We cannot get too many people working on this.  It is
   24:      not difficult to write a test, find a definition of the function
   25:      which I normally can provide, if necessary, and start writing tests
   26:      to test for compliance.  Beside this, take a look at the sources
   27:      and write tests which in total test as many paths of execution as
   28:      possible.
   29: 
   30: 
   31: [ 4] Write translations for the GNU libc message for the so far
   32:      unsupported languages.  GNU libc is fully internationalized and
   33:      users can immediately benefit from this.
   34: 
   35:      Take a look at the matrix in
   36:         ftp://ftp.gnu.org/pub/gnu/ABOUT-NLS
   37:      for the current status (of course better use a mirror of ftp.gnu.org).
   38: 
   39: 
   40: [ 8] If you enjoy assembler programming (as I do --drepper :-) you might
   41:      be interested in writing optimized versions for some functions.
   42:      Especially the string handling functions can be optimized a lot.
   43: 
   44:      Take a look at
   45: 
   46:         Faster String Functions
   47:         Henry Spencer, University of Toronto
   48:         Usenix Winter '92, pp. 419--428
   49: 
   50:      or just ask.  Currently mostly i?86 and Alpha optimized versions
   51:      exist.  Please ask before working on this to avoid duplicate
   52:      work.
   53: 
   54: 
   55: [11] Write access function for netmasks, bootparams, and automount
   56:      databases for nss_files, nss_nis, and nss_nisplus modules.
   57:      The functions should be embedded in the nss scheme.  This is not
   58:      hard and not all services must be supported at once.
   59: 
   60: 
   61: [15] Cleaning up the header files.  Ideally, each header style should
   62:      follow the "good examples".  Each variable and function should have
   63:      a short description of the function and its parameters.  The prototypes
   64:      should always contain variable names which can help to identify their
   65:      meaning; better than
   66: 
   67:                 int foo (int, int, int, int);
   68: 
   69:      Blargh!
   70: 
   71: ***  The conformtest.pl tool helps cleaning the namespace.  As far as
   72:      known the prototypes all contain parameter names.  But maybe some
   73:      comments can be improved.
   74: 
   75: 
   76: [18] Based on the sprof program we need tools to analyze the output.  The
   77:      result should be a link map which specifies in which order the .o
   78:      files are placed in the shared object.  This should help to improve
   79:      code locality and result in a smaller footprint (in code and data
   80:      memory) since less pages are only used in small parts.
   81: 
   82: 
   83: [19] A user-level STREAMS implementation should be available if the
   84:      kernel does not provide the support.
   85: 
   86: ***  This is a much lower priority job now that STREAMS are optional in
   87:      XPG.
   88: 
   89: 
   90: [20] More conversion modules for iconv(3).  Existing modules should be
   91:      extended to do things like transliteration if this is wanted.
   92:      For often used conversion a direct conversion function should be
   93:      available.
   94: 
   95: 
   96: [23] The `strptime' function needs to be completed.  This includes among
   97:      other things that it must get teached about timezones.  The solution
   98:      envisioned is to extract the timezones from the ADO timezone
   99:      specifications.  Special care must be given names which are used
  100:      multiple times.  Here the precedence should (probably) be according
  101:      to the geograhical distance.  E.g., the timezone EST should be
  102:      treated as the `Eastern Australia Time' instead of the US `Eastern
  103:      Standard Time' if the current TZ variable is set to, say,
  104:      Australia/Canberra or if the current locale is en_AU.
  105: 
  106: 
  107: [27] ...deleted...