git/list[1] front-page[2] threads[3] people[4] search[5] about
 

Re: [RFC PATCH 1/1] Add a type for errors

From
brian m. carlson <sandals@crustytoothpaste.net>
Date
Sep 30, 2024, 23:35 UTC
Message-ID
<Zvs11sEe_6c_L8DA@tapette.crustytoothpaste.net>
In-Reply-To
<xmqqv7yc3goa.fsf@gitster.g>
On 2024-09-30 at 22:44:37, Junio C Hamano wrote:
Show 15 quoted lines
> "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
Previous: Junio C HamanoNext: Patrick Steinhardt
Message 4 of 21 in “Typed errors”
  1. 0/1 Typed errorsbrian m. carlson, Sep 30, 2024
  2. 1/1 Add a type for errorsbrian m. carlson, Sep 30, 2024
  3. Junio C HamanoSep 30, 2024
  4. brian m. carlsonSep 30, 2024
  5. Patrick SteinhardtOct 21, 2024
  6. Oswald BuddenhagenOct 1, 2024
  7. Phillip WoodOct 2, 2024
  8. Emily ShafferOct 1, 2024
  9. brian m. carlsonOct 2, 2024
  10. Phillip WoodOct 2, 2024
  11. brian m. carlsonOct 2, 2024
  12. Eric SunshineOct 2, 2024
  13. brian m. carlsonOct 2, 2024
  14. Eric SunshineOct 3, 2024
  15. Junio C HamanoOct 3, 2024
  16. Eric SunshineOct 3, 2024
  17. brian m. carlsonOct 4, 2024
  18. phillip.wood123@gmail.comOct 4, 2024
  19. Richard KerryOct 4, 2024
  20. Emily ShafferOct 3, 2024
  21. phillip.wood123@gmail.comOct 4, 2024

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.