-
Couldn't load subscription status.
- Fork 13.9k
Stop at the first NULL argument when iterating argv
#106001
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
Conversation
|
(rustbot has picked a reviewer for you, use r? to override) |
|
Hey! It looks like you've submitted a new PR for the library teams! If this PR contains changes to any Examples of
|
18e14d5 to
ec1c6cf
Compare
Some C commandline parsers (e.g. GLib and Qt) are replacing already handled arguments in `argv` with `NULL` and move them to the end. That means that `argc` might be bigger than the actual number of non-`NULL` pointers in `argv` at this point. To handle this we simply stop iterating at the first `NULL` argument. `argv` is also guaranteed to be `NULL`-terminated so any non-`NULL` arguments after the first `NULL` can safely be ignored. Fixes rust-lang#105999
ec1c6cf to
e97203c
Compare
NULL arguments on Linux/glibc when iterating argvNULL argument when iterating argv
|
Is there anything I can help to move this forward? It would be great if this wouldn't cause crashes anymore 😅 |
|
@joshtriplett As this basically implements what you suggested in the issues and this is assigned to you for review, is there anything I can help with to get this reviewed faster? |
|
Might be worth re-rolling the reviewer dice. r? libs |
|
Code looks good to me. I happy to accept this given this is a potential safety issue (or at least this PR is better than crashing). And josh's opinion that it's a perfectly valid way to parse argv:
Argument parsers mutating argv sounds like a very dicey situation and Rust's std should play it safe. @bors r+ |
Rollup of 9 pull requests Successful merges: - rust-lang#105019 (Add parentheses properly for borrowing suggestion) - rust-lang#106001 (Stop at the first `NULL` argument when iterating `argv`) - rust-lang#107098 (Suggest function call on pattern type mismatch) - rust-lang#107490 (rustdoc: remove inconsistently-present sidebar tooltips) - rust-lang#107855 (Add a couple random projection tests for new solver) - rust-lang#107857 (Add ui test for implementation on projection) - rust-lang#107878 (Clarify `new_size` for realloc means bytes) - rust-lang#107888 (revert rust-lang#107074, add regression test) - rust-lang#107900 (Zero the `REPARSE_MOUNTPOINT_DATA_BUFFER` header) Failed merges: r? `@ghost` `@rustbot` modify labels: rollup
|
Can this also be backported to beta so it ends up in 1.68? |
|
We usually only backport regression fixes I think. @Mark-Simulacrum do you think this qualifies for a backport? |
|
It's up to T-libs, but I would lean towards no. We land bugfixes routinely and don't typically backport them. This is a soundness fix I guess, but only in edge cases, so I don't think it should merit special consideration. |
|
@rust-lang/libs should this be backported to beta? |
|
I've added the "beta-nominated" label to make sure it gets discussed. This will indeed need t-libs sign off before being accepted (or not). |
Some C commandline parsers (e.g. GLib and Qt) are replacing already handled arguments in
argvwithNULLand move them to the end. That means thatargcmight be bigger than the actual number of non-NULLpointers inargvat this point.To handle this we simply stop iterating at the first
NULLargument.argvis also guaranteed to beNULL-terminated so any non-NULLarguments after the firstNULLcan safely be ignored.Fixes #105999