[Toybox] More find cleanup

[Felix Janda]

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