Re: string types

[Bruno Haible <bruno@clisp.org>]

Hi Tim,

> >>>   - providing primitives for string allocation reduces the amount of buffer
> >>>     overflow bugs that otherwise occur in this area. [1]
> >>> [1] https://lists.gnu.org/archive/html/bug-gnulib/2019-09/msg00031.html
> > ...
> We created a 'catch them all' string/buffer type plus API. It is a good
> compromise for all kinds of situations, works like a memory buffer but
> is guaranteed 0-terminated, allows custom stack buffers with fallback to
> heap if to small.
> 
> https://gitlab.com/gnuwget/wget2/blob/master/libwget/buffer.c
> 
> 
> There also is a sprintf functionality (glibc compatible) using these
> buffers - and the operation is well faster than glibc's sprintf-like
> functions for all format strings tested (tested back a few years). The
> code is also much smaller (380 C code lines), the return values are
> size_t. It doesn't support float/double.
> 
> https://gitlab.com/gnuwget/wget2/blob/master/libwget/buffer_printf.c
> 
> If there is serious interest, I could prepare modules for gnulib.

It is interesting that your solution does not only cover the simple cases
(string concatenation, etc.), but also the more complex one, possibly
with if()s in the generation logic, and all this without blatant potential
for buffer overflow bugs.

So, the solution would consists of the following parts:
  (A) A growable buffer type, with up to N (128 or 1024 or so) bytes on
      the stack.
  (B) A set of functions for appending to such a growable buffer.
  (C) A function for creating a heap-allocated 'char *' from a growable
      buffer.
  (D) Short-hand functions for the simple cases (like string concatenation).

It would be good to have all these well integrated (in terms of function
names and calling conventions). So far, in gnulib, we have only pieces of
it:
  - Module 'scratch_buffer' is (A) without (B), (C), (D).
  - Modules 'vasnprintf', 'asprintf' are (B), (C), (D) but without (A).

Before you start writing the code, it's worth looking at the following
questions:
  * Should the module 'scratch_buffer' be reused for (A)? Or is this
    not possible? If not, can it still have a memory-leak prevention
    like described in lib/malloc/scratch_buffer.h?
  * What about reusing the complete vasnprintf.c for (B), rather than
    adding another, limited printf-like implementation?
  * Is it best to implement (D) based on (A), (B), (C), or directly
    from scratch?

Bruno