[Toybox] A ps cleanup I can't test...

[enh]

On Tue, Jan 14, 2025 at 12:45 PM Rob Landley <rob at landley.net> wrote:
>
> On 1/14/25 10:36, enh wrote:
> > On Sun, Jan 12, 2025 at 3:38 PM Rob Landley <rob at landley.net> wrote:
> >>
> >> Elliott, could you give this a sniff/smoke test on android? Built with
> >> the NDK it's giving blank space for PCY on all the processes I've got,
> >> which seems right according to the logic (before and after), but maybe
> >> not intentional?
> >>
> >>     $ cat /proc/self/cgroup
> >>     0::/1
> >>
> >> It's "-" if the file couldn't be opened, but "  " if the file exists but
> >> doesn't start with ":cpuset:/"? And then also "  " for
> >> "system-background"...
> >
> > yeah, i noticed that last time i touched this code and left it because
> > i thought it was potentially non-useless given that i spend my life
> > remotely debugging unreproducible things and the distinction might be
> > a useful clue. but, no, i have no concrete use for this.
>
> I'm not trying to remove it, just want to make sure I didn't
> accidentally break it in a way it wasn't previously broken. :)
>
> > note that the strstart() part is wrong because there's an integer
> > before ":cpuset:/" which is why there was a strstr() rather than a
> > strcmp() in the original.
>
> Case in point...
>
> > this modified version works correctly though:
>
> I'm assuming your change was just putting the strstr/strlen back?

correct.

> Alas, no stpstr()...
>
> Hm, if there's _always_ an integer there I could do sscanf(buf,
> "%*u:cpuset:/%n", &j). Except for the part it returns zero even if it
> didn't match because %n doesn't increment the hit count, so I'd have to
> initialize j to 0 and test j being nonzero. Sigh...

(yeah, that was roughly my journey when i first wrote this :-( )

> (It's just that having the same string constant listed in the source
> twice reads as a rough edge. Even if the compiler is nuts enough to
> resolve the strlen() at compile time, which is not a thing a compiler
> should be doing. Yeah yeah, tiny gripe...)

(aye, but gcc and clang _do_ do that. even through _FORTIFY_SOURCE.)

> WHY does man 3 sscanf say that %u is deprecated? Nevermind, I don't want
> to know and will be ignoring it.
>
> Right, stop picking at it, leave the duplicate string for now, commit
> 2e9d5017306c lemme know if I broke anything.

yes, results from that look the same as before on my test device. thanks!

> Thanks,
>
> Rob