Re: stack module

[Bruno Haible <bruno@clisp.org>]

Hi Marc,

> The alternative with the same type safety would be a source file with
> stack code procedures meant for inclusion (without include guards).
> The source file would expect a preprocessor defines GL_STACK_NAME,
> GL_STACK_TYPE, and GL_STACK_EXTERN.
> 
> The file itself would contain code like the following:
> 
> #define _GL_STACK_PREFIX(name) _GL_CONCAT(GL_STACK_NAME, _GL_CONCAT(_, name))
> 
> typedef struct
> {
>   GL_STACK_TYPE *base;
>   size_t size;
>   size_t allocated;
> }
> GL_STACK_PREFIX(type);
> 
> GL_STACK_EXTERN GL_STACK_PREFIX(init) (GL_STACK_PREFIX(type) *stack)
> {
>   stack->base = NULL;
>   stack->size = 0;
>   stack->allocated = 0;
> }
> 
> ...
> 
> The advantage of this model is that it generalizes to other data
> structures, for which a sole (or at least simple) macro implementation
> is not possible.

This is perfectly acceptable for Gnulib. It has debuggability and type safety.

You have precedent e.g. in lib/diffseq.h and lib/aligned-malloc.h.

You can even omit the 'GL_' prefix from the macro names. The user can #undef
the macros after including the file; therefore there is nearly no risk of
collision with macros defined by other code.

Bruno