Re: PATCH: move $ERRNO to the system module

[Bart Schaefer <schaefer@brasslantern.com>]

On Thu, Jan 12, 2023 at 9:15 AM Daniel Shahaf <d.s@daniel.shahaf.name> wrote:
>
> Does moving $ERRNO from the core to a module "reorder or add system
> calls" to the codepath that expands/evaluates uses of ERRNO?

As far as I can tell system call changes would only occur in
circumstances where the module could not be loaded at all.  On the
other hand, that circumstance also renders ERRNO useless.

> Oliver Kiddle wrote on Wed, 11 Jan 2023 23:19 +00:00:
> > ERRNO predates the system module, and loadable modules in general.

It doesn't just predate the system module, it predates the zsh source
import to git.

> > The trick with defining it as PM_UNSET doesn't
> > appear to work from a module.

Hm, that might be worthy of some further digging.

Aside, is Src/modentry.c present for any reason other than as some
kind of example?  It's been around since at least 2007 (workers/23479,
approximately) but it's not referenced anywhere, not even in
zsh-development-guide.

> Well, it's backwards incompatible and I don't understand the
> justification given, so I can't say I'm +1 on this.

On the one hand, workers/32337 already made a backwards-incompatible
change to ERRNO in the name of POSIX script compatibility, so any
really old scripts that used it will already have needed updating.
Moving it to a module is just another step in that direction, and
actually fixes the "must set before use" issue (obviously by replacing
it with "must load module before use").

On the opposing hand, the existence/use of ERRNO has been recently
discussed on the lists, the change to document the previous
incompatible change is also recent, and there have been other changes
to make the value of ERRNO more correctly reflect actual error states.
So his might not be an ideal time to introduce yet another such
change.

I'm net-zero on this.