[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
- Re: Add gl_list_remove_last to list/xlist, Bruno Haible, 2020/05/01
- Re: Add gl_list_remove_last to list/xlist, Marc Nieper-Wißkirchen, 2020/05/02
- Re: Add gl_list_remove_last to list/xlist, Bruno Haible, 2020/05/02
- Re: Add gl_list_remove_last to list/xlist, Marc Nieper-Wißkirchen, 2020/05/02
- Re: Add gl_list_remove_last to list/xlist, Bruno Haible, 2020/05/02
- Re: Add gl_list_remove_last to list/xlist, Marc Nieper-Wißkirchen, 2020/05/02
- Re: Add gl_list_remove_last to list/xlist, Marc Nieper-Wißkirchen, 2020/05/22
- Re: stack module, Bruno Haible, 2020/05/23
- Re: stack module, Marc Nieper-Wißkirchen, 2020/05/23
- Re: stack module,
Bruno Haible <=
- Re: stack module, Marc Nieper-Wißkirchen, 2020/05/23
- Re: stack module, Paul Eggert, 2020/05/23
- Re: stack module, Marc Nieper-Wißkirchen, 2020/05/23
- Re: stack module, Paul Eggert, 2020/05/23
- Re: stack module, Marc Nieper-Wißkirchen, 2020/05/23
- Re: stack module, Paul Eggert, 2020/05/23
- Re: stack module, Marc Nieper-Wißkirchen, 2020/05/23
- Re: stack module, Paul Eggert, 2020/05/23
- Re: stack module, Marc Nieper-Wißkirchen, 2020/05/23
- Re: stack module, Bruno Haible, 2020/05/23