Re: Does anybody use Gnulib's eealloc module?

[Bruno Haible]

Hi Paul,

Paul Eggert wrote:
> Does any package use Gnulib's eealloc module?

None, according to codesearch.debian.net.

And 'safe-alloc' is used by just 1 package: augeas.

> Although it seems to code stolen from Coreutils in 2006

That's probably because the header says:

   Written by Bruno Haible <bruno@clisp.org>, 2003,
   based on prior work by Jim Meyering.

> If nobody's using it, though, we should just remove it or mark it 
> obsolescent or obsolete or whatever.

"deprecated" would be the right term, according to our documentation [1].

> I'm asking because if people use the eealloc module, it should be 
> updated for C23's realloc semantics (and probably other things).

No, it shouldn't be updated to produce undefined behaviour, like C23 says.
And no, it shouldn't be deprecated or removed either.

It helps to ask ourselves: Why are we in the current mess w.r.t. realloc()?

The mess comes in two steps:

1) What the standards bodies standardized.

   There are two schools of thought:
     - A standard function should follow the mathematically sound way, that
       is, the one that treats 0 like any other nonnegative integer.
     - A standard function should encode existing practice (in this case,
       the *BSD and Solaris behaviour).

   The problem is that the standards bodies (regarding malloc and realloc)
   were torn apart between both, sometimes following one and sometimes
   following the other school of thought. This continues until now and
   will continue in the future.

2) What we in Gnulib did.

   We asked ourselves the question: "How should Gnulib's malloc, realloc
   behave, given the standards and existing practice?"

   There are three possible answers, already in 2003:
     (a) Choose the mathematically sound way: size = 0 is like size = 1.
     (b) Choose what glibc does, since we are _GNU_lib.
     (c) Discourage the use of malloc(0) and realloc(p,0).

   (a) is what the 'eealloc' module does.
   (b) is what we ended up doing. Following what glibc does is generally
       a successful recipe. But we did not realize that what glibc does could
       change in the future.
   (c) is what I suggested in [2], but it was controversial.

   Historically:

   In [2] I suggested that application code should call malloc() and realloc()
   directly, for micro-optimization reasons. That is, (c).

   Then, in [3] it was argued that (a) or (b) is better. For malloc() only,
   (a) and (b) are identical, and we didn't think much about realloc().

   In [4][5] I then implemented (a) as module 'eealloc'. The idea was that
   xmalloc() and xrealloc() should make use of it, but it never materialized.

   And by 2010, we generally had converged on (b), and called the modules
   'malloc-gnu' and 'realloc-gnu'.

Now, what is the way forward?

  * (c) is NOT generally recommendable, because it requires that the programmer
    reviews every malloc() and realloc() call — both in existing and in new
    code —, to guarantee that the size argument is always > 0. Some few
    packages may do this, but in general one cannot expect that programmers
    will do this 100% correctly.

  * Yesterday, you changed xrealloc() to implement behaviour (a) instead of (b).
    I like this, because (a) is future-proof and not dependent on the ad-hoc
    thoughts of standards committees.

  * Accordingly, we should probably deprecate the 'realloc-gnu' module and
    instead promote the use of a similar module with the (a) semantics. That is,
    like xrealloc() but without a call to xalloc_die().

    How could we call this module? 'realloc-ee' sounds too synthetic.

  * And, going along with that, we should promote the use of module 'eealloc'
    for libraries (that cannot use module 'xalloc').

Bruno

[1] https://www.gnu.org/software/gnulib/manual/html_node/Module-description.html
[2] https://lists.gnu.org/archive/html/bug-gnulib/2003-01/msg00040.html
[3] https://lists.gnu.org/archive/html/bug-gnulib/2003-01/msg00041.html
[4] https://lists.gnu.org/archive/html/bug-gnulib/2003-11/msg00111.html
[5] https://lists.gnu.org/archive/html/bug-gnulib/2004-01/msg00014.html