Sounds good, no objection from me — happy to go with your version. One small ask: since this fixes the issue from my original patch, could you add a Reported-by: Anshuman Tewari <[email protected]> when you post/apply it?
Thanks! On Fri, 21 Aug 2026 at 21:48, David Hildenbrand (Arm) <[email protected]> wrote: > > On 8/21/26 18:09, Anshuman Tewari wrote: > > Thanks David, agreed — strdup() is overkill here for a single-use > > parse, and dropping it is the right call. > > > > One small consideration on the approach: working on argv[0] in place > > means strsep() will overwrite the : separator with '\0', so the > > original string (e.g. "khugepaged:anon") ends up truncated after > > parsing. Nothing today reads argv[0] again afterward, so it's safe as > > things stand, but it does mean correctness quietly depends on that > > staying true — a future change that logs argv[0], re-parses it, or > > echoes it back in an error/usage message would get the mutated version > > instead of what the user actually typed. > > > > If we'd rather not rely on that invariant, an alternative that still > > avoids strdup()/free() entirely: copy the type argument into a small > > fixed-size stack buffer (with a bounds check against its length first) > > and run strsep() on that copy instead of on argv[0] directly. Same > > benefit as your version — no allocation, nothing to free, no > > NULL-check needed — but argv[0] itself stays untouched. > > > > Happy to write this up as a v2 if it seems worthwhile, or if you think > > relying on "nothing downstream needs argv[0]" is fine as-is, I'm okay > > going with your version too. Your call. > > I don't think we have to worry about other such argv[0] users. If they ever > appear, basic testing would reveal them. > > -- > Cheers, > > David
