From: Bart Schaefer <firstname.lastname@example.org>
Subject: Re: PATCH: move $ERRNO to the system module
Date: Mon, 16 Jan 2023 13:34:22 -0800 [thread overview]
Message-ID: <CAH+w=7Zp-Rhf9NsXsh0+mMa3GUd2VGqu5R+p=_0Hvf17xkK9-A@mail.gmail.com> (raw)
On Thu, Jan 12, 2023 at 9:15 AM Daniel Shahaf <email@example.com> 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
> 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
I'm net-zero on this.
prev parent reply other threads:[~2023-01-16 21:35 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-01-11 23:19 Oliver Kiddle
2023-01-12 8:47 ` Stephane Chazelas
2023-01-12 17:14 ` Daniel Shahaf
2023-01-16 21:34 ` Bart Schaefer [this message]
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).