On 04/21/13 at 12:38pm, Rob Landley wrote: > On 04/20/2013 01:39:10 PM, Felix Janda wrote: > > Hello, > > > > some more find cleanup in an attached patch. > > > > The main change was to make some code in build_filter_list() less > > repetitive using a suitable struct and a loop. > > Problem: you defined a struct locally, then used that structure > definition in GLOBALS. This works for buliding find itself, but breaks > for building every other command, because they haven't got this > structure definition. > > [snip] > > (If there's a good enough reason you can throw the structure definition > into lib/lib.h but the rule of thumb there is "used by more than one > command".)
Is this no longer relevant because of the following? On 04/21/13 at 12:40pm, Rob Landley wrote: > Huh, it didn't complain building defconfig. (Presumably because it's a > pointer not an instance of the struct, so it didn't care about the > sizeof the struct because that doesn't affect the sizeof the pointer.) > > *shrug* Learn something new every day... > > Rob > > The command line parsing > > is however now less efficient since after an argument has been tested > > for equality with different strings like "-mtime" and the > > corresponding > > type (CHECK_MTIME) has been saved, the saved integer has again to be > > checked for equality with stuff to find out what further command line > > parsing is necessary. > > An integer check is trivial. String comparisons do an order of > magnitude more work and evict cache lines in the process. On processors > with multiple execution units (on x86 that's everything since the > original pentium) an extra integer operation may even use an otherwise > idle execution unit so literally take no time at all. (Branches can be > expensive, it depends.) Ok, I thought more about the extra jumping around than about the integer checks. But actually it should only 2 additional jumps (jumping to the case label and jumping out of the switch with "break"). > I'm sure I've written up the whole spiel about "branch prediction and > register renaming, and why the embedded world chooses not to" at some > point. If I was more awake I could probably not only find it but work > in a joke about at quoted block's structural parallels to the full > title of The Hobbit. Lemme know if you're curious enough for me to redo > it here... No thanks. > > BTW: POSIX-1.2008 TC1 is out > > I might be happy about this if they hadn't deleted the original > Posix-2008 to post 5 years of updates all at once (Posix-2001 to > Posix-2008 was only 7 years) without an obvious changelog. (It says the > rationale has one, but that's just "why we removed tar and cpio in > favor of a pax command nobody will ever use, why we decided not to > include chroot, su, mknod, login, dc because who uses _that_..." All > 2008 decisions, no 2013 diffs.) > > Instead, I'm kind of annoyed about it. Luckily, I downloaded the old > one. > > (Version control, guys. It's a thing.) Isn't there a CHANGE HISTORY for each command? Is for example the -path primary new for find? Not that this diff format is very handy. Felix > Rob _______________________________________________ Toybox mailing list Toybox@lists.landley.net http://lists.landley.net/listinfo.cgi/toybox-landley.net