On Thu, Dec 1, 2022 at 12:06 PM Rob Landley <[email protected]> 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 >
_______________________________________________ Toybox mailing list [email protected] http://lists.landley.net/listinfo.cgi/toybox-landley.net
