On Wed, 02 Sep 2026 at 17:59, Matthias van de Meent <[email protected]> wrote: > On Wed, 2 Sept 2026 at 17:32, Japin Li <[email protected]> wrote: >> >> On Wed, 02 Sep 2026 at 13:36, Matthias van de Meent >> <[email protected]> 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. >> > >> >> +1 for this idea. >> >> Should we adopt the new glist interface in the existing code to better >> showcase its intended use? > > Did you have a place in mind where we have dlist and dclist in use to > track the same information in different build configurations?
I don't have such a place in mind. > I don't > like churning code for the sake of new APIs, especially when those new > APIs are not strictly better than the current ones. > > Note that I add glist to solve ergonomics issues when you want to > handle both types of lists. It's not meant to be used as default API > to fields that are always of a dlist type, or always of a dclist type, > even if it could be used like that. > If there is no code that actually uses it, I don't see a justification for adding it, especially given the concern about code churn. > > Kind regards, > > Matthias van de Meent > Databricks (https://www.databricks.com) -- Regards, Japin Li ChengDu WenWu Information Technology Co., Ltd.
