Messages in this thread | | | Subject | Re: [PATCH] consolidate all within() implementations | From | Peter 1 Oberparleiter <> | Date | Wed, 21 May 2008 15:50:22 +0200 |
| |
Peter Zijlstra <a.p.zijlstra@chello.nl> wrote on 21.05.2008 12:48:52:
> On Wed, 2008-05-21 at 12:33 +0200, Peter 1 Oberparleiter wrote: > > Peter Zijlstra <a.p.zijlstra@chello.nl> wrote on 21.05.2008 12:04:26:
> peter@lappy:~/tmp$ gcc -S -Os cmp*.c > peter@lappy:~/tmp$ ls -la cmp*.o > -rw-r--r-- 1 peter peter 752 2008-05-21 12:43 cmp2.o > -rw-r--r-- 1 peter peter 743 2008-05-21 12:43 cmp.o
Yeah, but!
[oberpar@local cmp]$ gcc -c -O2 cmp*.c [oberpar@local cmp]$ ls -la cmp*.o -rw-r--r-- 1 oberpar oberpar 1352 May 21 15:40 cmp2.o -rw-r--r-- 1 oberpar oberpar 1408 May 21 15:40 cmp.o
:)
> Also look at the .s output and notice mine doesn't have any additional > branches ;-)
It really boils down to the question whether you want to trade a bit of obviousness for a bit of efficiency/clever programming. I vote for keeping the former.
> > > static inline int > > > addr_within(const void *add, const void *start, const void *end) > > > { > > > return addr_within_len(addr, start, > > > (unsigned long)end - (unsigned long)start); > > > } > > > > For empty ranges (start > end), this produces different (less expected) > > results than the previous version. > > agreed, do we care about those?
Why not plan for the unexpected when it comes at little cost?
Regards, Peter
| |