Re: unhide reallocarray

[Robert Elz <kre%munnari.OZ.AU@localhost>]

  | On Tue, 30 Aug 2022, Thomas Klausner wrote:
  |
  | > So I'd like to put it outside of the _OPENBSD_SOURCE #ifdef

    Date:        Tue, 30 Aug 2022 22:13:51 +0000 (UTC)
    From:        RVP <rvp%SDF.ORG@localhost>
    Message-ID:  <6d38a97c-7b21-2cce-a4f-af4486c064b5%SDF.ORG@localhost>

  | Go for it.

If this happens, don't forget to make appropriate adjustments to
the man page.

This might also be an appropriate time to fix the man page for
reallocarr(3) so it actually says something more than giving one
(mediocre) example.

The man page for reallocarray() says that reallocarr() was created
to avoid the ambiguity with 0 sized allocations (which stems from
realloc() in posix - because some realloc() implementations behaved
differently than others).   We could have simple defined what our
versions of realloc() and reallocarray() do in this case (posix lists
it as implementation defined - not unspecified, or worse, undefined)
but we didn't, and that's understandable, it makes it clear which
code is expecting the NetBSD definition for what happens, and which
might be expecting someone else's.

However, the man page for reallocarr() doesn't say what happens if
the allocation turns out to be for a 0 sized chunk.   That makes it
just as ambiguous (if not more so) than the posix version.

In fact, our man page doesn't sat almost anything about what reallocarr()
does, we are apparently simply supposed to guess.

DESCRIPTION
     The reallocarr function reallocates the memory in *ptr.

That's it.   The other two (size_t) parameters are apparently ignored
(or at least have unspecified uses).

Of course, if one believes that a section called EXAMPLES is part of
the specification, then one can guess what is supposed to happen, but
neither the 2 example calls in that example give any clue about what
might happen if either INITSIZE or NEWSIZE is 0.

Even then there's no clue given as to the correct procedure to
dispose of the memory when it is no longer needed.   "Obviously
use free(3)" is not adequate, nothing in the man page hints that
the memory is allocated by malloc() - it might just as easily be
a direct mmap().   Maybe reallocarr(&ptr, 0, 0) is the way we're
supposed to free it?

kre

ps: "the memory in *ptr" is particularly poor wording.  I would tend to
read that as (the thing that ptr points to) which in the example, is the
contents of data - where what is intended is the memory that data references,
if it is not NULL.

pps: a see also of just calloc(3) is inadequate, it should also referece
reallocarray(3) since that function is mentioned in the man page text,
and realloc(3) and malloc(3) as well, though they're both in the same page
as calloc(3).
that