From: "brian m. carlson" <sandals@crustytoothpaste.net>
To: Junio C Hamano <gitster@pobox.com>
Cc: git@vger.kernel.org, Emily Shaffer <nasamuffin@google.com>
Subject: Re: [RFC PATCH 1/1] Add a type for errors
Date: Mon, 30 Sep 2024 23:35:50 +0000 [thread overview]
Message-ID: <Zvs11sEe_6c_L8DA@tapette.crustytoothpaste.net> (raw)
In-Reply-To: <xmqqv7yc3goa.fsf@gitster.g>
[-- Attachment #1: Type: text/plain, Size: 1884 bytes --]
On 2024-09-30 at 22:44:37, Junio C Hamano wrote:
> "brian m. carlson" <sandals@crustytoothpaste.net> writes:
>
> > .... It is designed to be passed and returned by value, not
> > pointer, and it is possible to do so in two registers on 64-bit systems.
> > Similar functionality works well for error types in Rust and for the
> > standard library's lldiv_t, so this should not pose a problem.
>
> It should not, in the sense that "any reasonable platform should be
> able to pass two 64-bit word in a structure by value", but isn't it
> optimizing for a wrong (i.e. have error) case? In the case where
> there is no error, a "negative return is error, zero is success",
> with a pointer to "more detailed error info, in case the call
> resulted in an error", would let us take branch based on a zero-ness
> check on an integer in a machine-natural word, without even looking
> at these two words in the struct.
We can adjust the first word so that it's always zero on success, in
which case, because it's returned in two registers, the processor will
be able to branch on a zero-ness check on one of those registers. (We
can even optimize the check by looking at the low 32 bits, which will do
the same for 32-bit machines as well.) The performance benefit will be
the same, and I should note that Rust does this kind of thing without a
problem.
We did discuss passing an error accumulating argument to all functions
at the contributor summit, but it didn't seem that was the way folks
wanted to go: people seemed to prefer a return value.
I'm totally open to other proposals here and not particularly tied to
this one, but I told Emily that I'd send a proposal to the list, and so
here it is. If we like this with changes or prefer something different,
that's fine with me.
--
brian m. carlson (they/them or he/him)
Toronto, Ontario, CA
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 262 bytes --]
next prev parent reply other threads:[~2024-09-30 23:35 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-09-30 22:03 [RFC PATCH 0/1] Typed errors brian m. carlson
2024-09-30 22:03 ` [RFC PATCH 1/1] Add a type for errors brian m. carlson
2024-09-30 22:44 ` Junio C Hamano
2024-09-30 23:35 ` brian m. carlson [this message]
2024-10-21 12:46 ` Patrick Steinhardt
2024-10-01 15:29 ` Oswald Buddenhagen
2024-10-02 14:01 ` Phillip Wood
2024-10-01 20:31 ` Emily Shaffer
2024-10-02 21:51 ` brian m. carlson
2024-10-02 9:54 ` Phillip Wood
2024-10-02 22:04 ` brian m. carlson
2024-10-02 22:16 ` Eric Sunshine
2024-10-02 22:24 ` brian m. carlson
2024-10-03 5:14 ` Eric Sunshine
2024-10-03 16:05 ` Junio C Hamano
2024-10-03 22:27 ` Eric Sunshine
2024-10-04 0:15 ` brian m. carlson
2024-10-04 9:00 ` phillip.wood123
2024-10-04 12:13 ` Richard Kerry
2024-10-03 16:17 ` Emily Shaffer
2024-10-04 9:00 ` phillip.wood123
Reply instructions:
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:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=Zvs11sEe_6c_L8DA@tapette.crustytoothpaste.net \
--to=sandals@crustytoothpaste.net \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
--cc=nasamuffin@google.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* 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.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.