<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Dec 1, 2022 at 12:06 PM Rob Landley <<a href="mailto:rob@landley.net">rob@landley.net</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><br>
<br>
On 12/1/22 13:35, enh via Toybox wrote:<br>
> Not everyone wants -b, but that's the default for a tty, and we don't<br>
> currently have an opt out.<br>
> <br>
> To my surprise, -N (despite having the long name --literal) only<br>
> disables -b, not -q. There's a separate --show-control-chars (opposite<br>
> of --hide-control-chars, which is the long name for -q) for that, so -N<br>
> really is just "the opposite of -b".<br>
> <br>
> Since no-one's asked for --show-control-chars yet to my knowledge, I've<br>
> not implemented that here.<br>
> <br>
> Also add tests for -b/-q/-N.<br>
<br>
Applied, but this introduces a very subtle bug I think I need a design fix for:<br>
<br>
+  if (FLAG(N)) toys.optflags &= ~FLAG_b;<br>
<br>
Because generated/flags.h has:<br>
<br>
  #define FLAG_b (1<<18)<br>
  ...<br>
  #define FLAG_show_control_chars (1LL<<31)<br></blockquote><div><br></div><div>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?</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
  #define FLAG_full_time (1LL<<32)<br>
  #define FLAG_color (1LL<<33)<br>
<br>
I.E. mkflags.c only uses the "long long" type for a FLAG macro when the result's<br>
big enough to need it. This means that compiler produces slightly more efficient<br>
code (especially on 32 bit systems), but I suspect 64bit ~= ~(32bit) is going to<br>
zero out those top 32 bits because the type promotion isn't going to traverse<br>
the operations. Which means -n is also zapping at least two of those three<br>
longopts. (I think the 31 is because the 1 isn't an unsigned constant and some<br>
compiler version did a warning, but it's been a while...)<br>
<br>
I was comfortable with that because _I_ remember that ls is one of the few<br>
commands using more than 32 flags and thus you have to worry about this type<br>
transition, but once the mistake's been innocently made I need to remove the<br>
sharp edge. Probably if a command HAS more than 31 flags, then all its flag<br>
macros should be long.<br>
<br>
(Which still potentially leaves a sharp edge using FORCED_FLAGS with two<br>
different commands in the same .c file only one of which has large flags. Hmmm.<br>
toys.optflags is always 64 bit, it's just the macro generation that's doing<br>
this. I could always use 1LL and let the compiler simplify the math I guess? I<br>
just don't trust the compiler to actually do that, and 64 bit math on 32 bit<br>
does that whole FOIL algebra with libgcc function calls...)<br></blockquote><div><br></div><div>_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...</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
Anyway, applied, I should squint at it more after lunch...<br>
<br>
Rob<br>
</blockquote></div></div>