Hi Willy, I fully understand what you said. And I also think I need to give it some serious thought.
Additionally, Is there any part of the discussion regarding malloc() or other areas where I can contribute that I can participate in? Recently, after digging into a lot of haproxy source code, I'm willing to study more and contribute to the core components :) Thanks. Hyeonggeun Oh. On Mon, Jan 12, 2026 at 4:12 PM Willy Tarreau <[email protected]> wrote: > On Fri, Dec 26, 2025 at 03:57:33PM +0900, Hyeonggeun Oh wrote: > > Currently, variable names are only used during parsing and are not > > stored at runtime. This makes it impossible to iterate through > > variables and retrieve their names. > > > > This patch adds infrastructure to store variable names: > > - Add 'name' and 'name_len' fields to var_desc structure > > - Add 'name' field to var structure > > - Add VDF_NAME_ALLOCATED flag to track memory ownership > > - Store names in vars_fill_desc(), var_set(), vars_check_arg(), > > and parse_store() > > - Free names in var_clear() and release_store_rule() > > > > Changes based on Willy's feedback: > > - Use ha_free() instead of free() in var_clear() to prevent > use-after-free issues > > - Use my_strndup() instead of strndup() for cross0platform compatibility > > - Move variable declarations to the beginning of functions > (vars_check_arg and parse_store) > > - Fail explicitly when memory allocation fails: > > - In var_set(): free the variable and return failure > > - In vars_check_arg(): return error with "out of memory" message > > - In parse_store(): return ACT_RET_PRS_ERR with error message > > - Set VDF_NAME_ALLOCATED flag only when allocation succeeds > > - This ensures var->name is either NULL or allocated memory, never a > const pointer that souldn't be freed > > On this point, I'm thinking that later we might try to improve > this to save a malloc() for most use cases where the name comes > from an action's argument (which is already allocated). Since > you already have the VF_NAME_ALLOCATED flag, we should be able > to call var_set() with that flag when we know that the name is > already present so as to avoid a malloc in the fast path. But I > think it will require a fine audit to make sure we don't mess > up with anything. > > So for now this looks good to me. > > thanks, > Willy > >
