Skip to content

alloc: add useful try_* methods to String #476

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
wants to merge 1 commit into
base: rust
Choose a base branch
from

Conversation

jablonskim
Copy link

This commit adds the following methods to String structure:

  • try_with_capacity
  • try_push_str
  • try_shrink_to_fit
  • try_push
  • try_into_boxed_str

Those are panic-free equivalents of already existing methods.
They may be useful for String creation inside kernel code.

Signed-off-by: Mateusz Jabłoński [email protected]

This commit adds the following methods to `String` structure:
  - `try_with_capacity`
  - `try_push_str`
  - `try_shrink_to_fit`
  - `try_push`
  - `try_into_boxed_str`

Those are panic-free equivalents of already existing methods.
They may be useful for `String` creation inside kernel code.

Signed-off-by: Mateusz Jabłoński <[email protected]>
Comment on lines +463 to +468
/// let cap = s.capacity();
/// for _ in 0..10 {
/// s.push('a');
/// }
///
/// assert_eq!(s.capacity(), cap);
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Perhaps you can simply assert_eq!(s.capacity(), 10); before and after, since the capacity is known (i.e. we are guaranteeing exact capacity, rather than "at least", no?).

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We indeed guarantee it. From the capacity docs of Vec:

vec![x; n], vec![a, b, c, d], and Vec::with_capacity(n), will all produce a Vec with exactly the requested capacity.

@ojeda
Copy link
Member

ojeda commented Oct 26, 2021

Did you try to send this upstream? i.e. since we are not using them right now, perhaps we can pick them up from there instead.

Darksonn pushed a commit to Darksonn/linux that referenced this pull request Oct 30, 2024
Add a small test to write a (verification-time) fixed vs unknown but
bounded-sized buffer into .rodata BPF map and assert that both get
rejected.

  # ./vmtest.sh -- ./test_progs -t verifier_const
  [...]
  ./test_progs -t verifier_const
  [    1.418717] tsc: Refined TSC clocksource calibration: 3407.994 MHz
  [    1.419113] clocksource: tsc: mask: 0xffffffffffffffff max_cycles: 0x311fcde90a1, max_idle_ns: 440795222066 ns
  [    1.419972] clocksource: Switched to clocksource tsc
  [    1.449596] bpf_testmod: loading out-of-tree module taints kernel.
  [    1.449958] bpf_testmod: module verification failed: signature and/or required key missing - tainting kernel
  Rust-for-Linux#475/1   verifier_const/rodata/strtol: write rejected:OK
  Rust-for-Linux#475/2   verifier_const/bss/strtol: write accepted:OK
  Rust-for-Linux#475/3   verifier_const/data/strtol: write accepted:OK
  Rust-for-Linux#475/4   verifier_const/rodata/mtu: write rejected:OK
  Rust-for-Linux#475/5   verifier_const/bss/mtu: write accepted:OK
  Rust-for-Linux#475/6   verifier_const/data/mtu: write accepted:OK
  Rust-for-Linux#475/7   verifier_const/rodata/mark: write with unknown reg rejected:OK
  Rust-for-Linux#475/8   verifier_const/rodata/mark: write with unknown reg rejected:OK
  Rust-for-Linux#475     verifier_const:OK
  Rust-for-Linux#476/1   verifier_const_or/constant register |= constant should keep constant type:OK
  Rust-for-Linux#476/2   verifier_const_or/constant register |= constant should not bypass stack boundary checks:OK
  Rust-for-Linux#476/3   verifier_const_or/constant register |= constant register should keep constant type:OK
  Rust-for-Linux#476/4   verifier_const_or/constant register |= constant register should not bypass stack boundary checks:OK
  Rust-for-Linux#476     verifier_const_or:OK
  Summary: 2/12 PASSED, 0 SKIPPED, 0 FAILED

Signed-off-by: Daniel Borkmann <[email protected]>
Acked-by: Kumar Kartikeya Dwivedi <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Alexei Starovoitov <[email protected]>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

Successfully merging this pull request may close these issues.

3 participants