bug-gnulib
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: stack module


From: Bruno Haible
Subject: Re: stack module
Date: Sat, 23 May 2020 16:02:33 +0200
User-agent: KMail/5.1.3 (Linux/4.4.0-177-generic; KDE/5.18.0; x86_64; ; )

Hi Marc,

> > In Gnulib, we usually avoid extensive use of multi-line macros, because
> > it hampers debuggability. Here, however, one needs macros, in order to
> > accommodate the TYPE argument, which is not necessarily compatible to 'void 
> > *'.
> > Nevertheless, we would try to put as much code as possible into functions.
> > The STACK_INIT macro, for example, could be implemented as a function.
> 
> How? This would mean that the function stack_init has to take a void *
> argument, which has to be cast to
> 
> struct
> {
>   void *base; ...
> }
> 
> and we have to hope that this structure is guaranteed to be compatible to
> 
> struct
> {
>   type *base; ...
> }
> 
> by the C standard.

I was expecting that you write

  struct
  {
    void *base; ...
  }

and the cast the base to 'type *' each time you fetch it. I don't think this
would go the C standard, nor defeat any possible compiler optimization.

> > > #define STACK_CLEAR(stack)            \
> > >   free ((stack).base)
> >
> > Shouldn't this one also set .size and .allocated to 0 ?
> 
> A stack can be uninitialized or initialized. An uninitialized stack is
> initialized by STACK_INIT. It is cleared (and uninitialized) by
> STACK_CLEAR. An uninitialized stack does not have to maintain any
> invariant. The only way to use it is to initialize it again. Thus,
> setting .size and .allocated seems pointless.

Then macro should better be called STACK_FREE or STACK_DESTROY.

The name STACK_CLEAR suggests that the result is still a valid stack, and empty.

> > > #define STACK_POP(stack)            \
> > >   (stack).base [--(stack).size]
> > >
> > > #define STACK_DISCARD(stack)            \
> > >   (--(stack).size)
> > >
> > > #define STACK_TOP(stack)            \
> > >   (stack).base[(stack).size - 1]
> >
> > In these three macros, I would consider to abort() when (stack).size == 0.
> 
> In the form of assure of the assure module? Or, to facilitate
> optimization, better assume from verify module? In non-debug builds, I
> want to make sure that no superfluous checks are made.

The 'verify' module is for compile-time checks.

'assure' is an improved form of 'assert'.

Bruno




reply via email to

[Prev in Thread] Current Thread [Next in Thread]