On Wed, 2 Sept 2026 at 19:35, Tristan Partin <[email protected]> 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-=w8...@mail.gmail.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)
