[Toybox] [PATCH] ls -N.

[enh]

On Thu, Dec 1, 2022 at 12:06 PM Rob Landley <rob at landley.net> wrote:

>
>
> On 12/1/22 13:35, enh via Toybox wrote:
> > Not everyone wants -b, but that's the default for a tty, and we don't
> > currently have an opt out.
> >
> > To my surprise, -N (despite having the long name --literal) only
> > disables -b, not -q. There's a separate --show-control-chars (opposite
> > of --hide-control-chars, which is the long name for -q) for that, so -N
> > really is just "the opposite of -b".
> >
> > Since no-one's asked for --show-control-chars yet to my knowledge, I've
> > not implemented that here.
> >
> > Also add tests for -b/-q/-N.
>
> Applied, but this introduces a very subtle bug I think I need a design fix
> for:
>
> +  if (FLAG(N)) toys.optflags &= ~FLAG_b;
>
> Because generated/flags.h has:
>
>   #define FLAG_b (1<<18)
>   ...
>   #define FLAG_show_control_chars (1LL<<31)
>

oh, `toybox ls --help` made me assume we didn't have --show-control-chars
--- should i send a patch to add that to the help, or are you already doing
that as part of the cleanup below?


>   #define FLAG_full_time (1LL<<32)
>   #define FLAG_color (1LL<<33)
>
> I.E. mkflags.c only uses the "long long" type for a FLAG macro when the
> result's
> big enough to need it. This means that compiler produces slightly more
> efficient
> code (especially on 32 bit systems), but I suspect 64bit ~= ~(32bit) is
> going to
> zero out those top 32 bits because the type promotion isn't going to
> traverse
> the operations. Which means -n is also zapping at least two of those three
> longopts. (I think the 31 is because the 1 isn't an unsigned constant and
> some
> compiler version did a warning, but it's been a while...)
>
> I was comfortable with that because _I_ remember that ls is one of the few
> commands using more than 32 flags and thus you have to worry about this
> type
> transition, but once the mistake's been innocently made I need to remove
> the
> sharp edge. Probably if a command HAS more than 31 flags, then all its flag
> macros should be long.
>
> (Which still potentially leaves a sharp edge using FORCED_FLAGS with two
> different commands in the same .c file only one of which has large flags.
> Hmmm.
> toys.optflags is always 64 bit, it's just the macro generation that's doing
> this. I could always use 1LL and let the compiler simplify the math I
> guess? I
> just don't trust the compiler to actually do that, and 64 bit math on 32
> bit
> does that whole FOIL algebra with libgcc function calls...)
>

_most_ 64-bit math won't (at least not on arm/x86, which are the only
32-bit systems i still see). it's not like you're multiply or dividing
here...


> Anyway, applied, I should squint at it more after lunch...
>
> Rob
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.landley.net/pipermail/toybox-landley.net/attachments/20221201/78b72eb9/attachment.htm>