Re: How does zsh internally store and process variables?

[Bart Schaefer <schaefer@xxxxxxxxxxxxxxxx>]

On Sat, Jan 27, 2024 at 2:00 PM vlkr1 <vlkr1@xxxxxxxxx> wrote:
>
> One of the things that we are having trouble with are internal variables.

Have you looked at Etc/zsh-development-guide in the zsh distribution?

There's a section on "Parameters" and how modules should make use of
them.  It's mostly focused on how modules can add their own parameters
rather than on how to access existing parameters, but the basics of
the structures and accessors are all explained (albeit with pointers
to zsh.h for structure definitions).

As a side-effect of evolutionary development, zsh uses a single global
pointer "paramtab" for most of the get/set functions, so it's not
threading-safe code and signal handling has to be carefully managed.
A second global pointer "realparamtab" points to the actual table for
all the variables, so you'll see tests for "paramtab == realparamtab"
in various places.  Internally, associative array key/value pairs are
implemented as parameter tables, so paramtab may point to the
internals of an associative array in some cases, where the associative
array itself is contained in realparamtab (we don't presently allow
them to nest).

In the current development git head, the files
Src/Modules/param_private.c and Src/Modules/ksh93.c may provide some
useful coding hints, although neither is exactly what you're after.

> how its variables are exported (setenv?)

There's a preprocessor definitions for HAVE_PUTENV and
USE_SET_UNSET_ENV.  Primarily these apply in the zgetenv(), zputenv(),
and delenv() functions defined in Src/params.c which are what you
should call, but there are lower-level functions if you really need
them or you can use #ifdef with those macros to choose the system
library routines.

> If the keys and values are copied or expected to be leaked/alloccd with malloc by the caller

Keys are managed by the functions in Src/params.c, so you can pass
constant strings e.g. as the first argument of setsparam() or the
other parameter functions.  String values (second parameter of
setsparam()) should be allocated by the caller but are freed by
Src/params.c when the value changes or is unset.  Values represented
by numeric types (int, float) are not memory-managed.

String values also need to be "metafied".  If you are copying them
from another parameter, they are likely already metafied.  If coming
from user input or the like, use for example ztrdup_metafy() to
allocate a metafied copy for setsparam().