aio-libs / multidict / 38255301201

86%

push

github

Return lookup results by value to keep stack canaries off get paths (#1781)

<!-- Thank you for your contribution! -->

## What do these changes do?

`md_calc_identity_hash()` and `md_get_one()` returned their results
through pointers to the caller's locals. Wherever GCC kept such a helper
out of line, the locals became address-taken, and
`-fstack-protector-strong` (Ubuntu's GCC default, and what CI and
CodSpeed build with) then gave the caller a stack canary: a TLS load, a
store and a compare on every call of `md[key]`, `get()` and `getone()`.
Both helpers now return a two-word struct by value (`identity_hash_t`,
`lookup_t`), the same fix #1664 applied to `parse2()`.

Without the address-taken arguments GCC stopped inlining
`md_calc_identity_hash()` into the owned-key path of `md_get_one()`,
which the `md_calc_identity_hash` rule in `tools/check_inlining.py`
caught, so `_md_get_one_owned()` computes the identity and hash itself.

On the free-threaded build the locked retries of get and contains,
`_md_get_one_retry_locked()` and `_md_contains_retry_locked()`, are
marked `COLD`, so their critical-section state, and its canary, stays
out of the lock-free fast path. They only run when a reader races a
writer.

The pure-Python backend needs nothing; no behaviour changed.

## Are there changes in behavior for the user?

No. Lookups are faster; see the measurements below.

## Is it a substantial burden for the maintainers to support this?

No. Two small result structs; `_md_get_one_owned()` repeats the five
lines of `md_calc_identity_hash()`, with a comment saying why.

## Related issue number

None.

## Checklist

- [x] I think the code is well written
- [x] Unit tests for the changes exist (N/A, no behavior changed; the
existing get/getone/`[]`/C API tests cover these paths)
- [x] Documentation reflects the changes (N/A, no documented behavior
changed)
- [ ] If you provide code modification, please add yourself to
`CONTRIBUTORS.txt` (N/A, this repo has no... (continued)

832 of 1664 branches covered (50.0%)

Branch coverage included in aggregate %.

9763 of 10652 relevant lines covered (91.65%)

1.83 hits per line