[Toybox] [PATCH] ulimit: actually use the units we claim.

[Rob Landley]

On 5/11/23 15:24, enh via Toybox wrote:
> it occurs to me we could have the best of both worlds if we check the final
> character of the argument? if it's a digit, use the multiplier; if it's not,
> assume the user already gave their preferred multiplier (and didn't mean "8k
> KiB" or "8m KiB" or whatever). even seems to make sense for the 512-byte pipe
> sizes? want me to send another patch on top of this?

I opened a window with this yesterday but haven't done much with it because I
haven't quite wrapped my head around the design/ui issue at stake. Compatibility
with bash: great. Randomly varying units: less great. (Also this first entry in
your new table RLIMIT_CORE says (block) but has a unit of 1024 which is neither
512 nor 4096 so it's... thousands of blocks? Also you're multiplying the units
AFTER capping the input range at LONG_MAX...)

Yes, _default_ units (when there's no unit specified on the input) makes (a
certain amount of) sense and is easy to detect. Supplied units would override
those instead of stacking. I was also pondering about putting units on the
output but "-l" saying "64k" suddenly gives consumers something else to parse
that's not good, so maybe some "all output is in bytes" command option would
still be good...

Also, the RLIMIT_BLAH macros in asm-generic.h go from 0 to 15 in a fixed order,
so just defining the table entries in that order (and reordering the flags to be
in that order) makes a chunk of the logic drop out...

Hence why I left the window open... :)

Rob