the obstack module

[Bruno Haible]

Hi Paul,

A number of things are wrong in the obstack module.

* It makes use of <gnu-versions.h> and an idiom described therein.
  This idiom is how Ulrich Drepper imagined glibc code to be used in
  GNU packages in 1997. This idiom was meant to be used for
    obstack
    regex
    glob
    getopt
  This idiom predates gnulib idioms by several years.
  For regex, glob, getopt it is no longer in use, only for obstack.
  This idiom, in particular, does not rename the symbols and therefore
  provokes collisions between the glibc symbols and the package's
  symbols. As we have seen by this week's bug report, this does not
  work reliably when dlopen() is being used.

* The m4/obstack.m4 file suggests that by setting gl_cv_func_obstack=yes
  I could use glibc's obstack facility instead of gnulib's obstack facility.
  But this does not work: It continues to use gnulib's obstack facility.
  (Maybe the way to achieve that is to #define _OBSTACK_INTERFACE_VERSION 1
  — but that's not documented.)

* When _OBSTACK_ELIDE_CODE is in effect, it leads to a compilation unit
  without any definitions. It is better to have no .o file at all in this
  case.

* Since the .h file is called obstack.h, not obstack.in.h, it needs to
  contain glibc's obstack.h as a special case, when _OBSTACK_INTERFACE_VERSION
  is defined to 1. This leads to divergence problems: glibc cannot make
  changes to its obstack.h, without requiring a corresponding change in
  gnulib. Rather than to use a glibc function together with a gnulib .h file,
  it is much better to use that glibc function together with glibc's .h file
  (as found in /usr/include). Which is what the *.in.h processing would do.
  A symptom of this problem is also these lines:

    #if _OBSTACK_INTERFACE_VERSION == 1
    /* For binary compatibility with obstack version 1, which used "int"
       and "long" for these two types.  */
    # define _OBSTACK_SIZE_T unsigned int
    # define _CHUNK_SIZE_T unsigned long
    # define _OBSTACK_CAST(type, expr) ((type) (expr))

  These lines should go away.

* This divergence problem that too closely ties the gnulib source code to
  the glibc ABI also makes it harder to add new functionality in Gnulib.

And maybe more.

Do you see a problem with fixing these things? May I go ahead and modernize
this?

Bruno