Re: glist: _Generic wrapper for selective dlist/dclist usage

On Wed, 2 Sept 2026 at 19:35, Tristan Partin <tristan(at)partin(dot)io> wrote:
>
> On Wed Sep 2, 2026 at 11:36 AM UTC, Matthias van de Meent wrote:
> > Hi,
> >
> > I'd like to track the size of a dlist for data structure validation
> > purposes[^0]. Normally, one would use a dclist, as this tracks a
> > count of list elements contained therein, but because this code would
> > not be called in most normal production builds using a dclist would
> > waste precious memory.
> > Manually tracking the length is possible, but tedious, and a local
> > wrapper around the used dclist/dlist APIs (with different
> > implementations conditioned with #ifdefs to use the right types) would
> > also be a significant amount of effort, that'd be duplicated every
> > time .
> >
> > Attached is a patch that adds glist_* macros, which wrap several
> > dlist/dclist_* APIs, so that developers can use dlist/dclist
> > selectively in different environments, without significant visual
> > overhead in the code. I'm planning to use this in the Proxy memory
> > contexts over at [1].
> >
> > I've considered also adding slist_* to the macros, but I've never
> > needed selective slist vs dlist/dclist before, so I ignored that list
> > type for now.
> >
> >
> > Kind regards,
> >
> > Matthias van de Meent
> > Databricks (https://www.databricks.com)
> >
> >
> > [^0]: This case for builds with MEMORY_CONTEXT_CHECKING, but builds
> > with USE_ASSERT_CHECKING or WRITE_READ_PARSE_PLAN_TREES -like options
> > may also want this.
> >
> > [1]: https://www.postgresql.org/message-id/flat/CAEze2WiPyruOtUOSyRUV8mQssjmYwno0M6hkxC_iUpH-=W8WcA(at)mail(dot)gmail(dot)com
>
> I can't speak much to the purpose, but the patch itself looks correct
> given my understanding of _Generic. I also checked that the dlist/dclist
> function names match up with the glist function names. Do you think it
> makes sense to add a comment of how one might use glist? There is
> a large comment at the top of ilist.h where it could make sense to add
> one if you think it would be useful.

Good idea.

> Maybe dglist would be a better name
> to keep it more scoped to doubly linked lists?

I'd like to avoid painting ourselves into a corner here; though I have
no current need for slist support, I also don't want to rule out that
someone else can find a need for it, and I think adding another copy
of the macros (instead of adapting existing ones) would be a shame.
So here I'd like to keep the scope open to adding slist.

Kind regards,

Matthias van de Meent
Databricks (https://www.databricks.com)