| lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
|
Open Source and information security mailing list archives
| ||
|
Message-ID: <CAAek22F3JzWRVqwf=QdaoowjTSkfHAiUP6orpHpcdt_gicaT=A@mail.gmail.com> Date: Tue, 24 Feb 2015 12:33:06 -0800 From: Phil Pokorny <ppokorny@...guincomputing.com> To: Bartosz Golaszewski <bgolaszewski@...libre.com> Cc: LKML <linux-kernel@...r.kernel.org>, lm-sensors <lm-sensors@...sensors.org> Subject: Re: [lm-sensors] [PATCH 1/4] kernel.h: add find_closest() macro On Tue, Feb 24, 2015 at 9:42 AM, Bartosz Golaszewski <bgolaszewski@...libre.com> wrote: > > Searching for the member of an array closest to 'x' is > duplicated in several places. > > Add two macros that implement this algorithm for arrays > sorted both in ascending and descending order. I don't see the point here. You're not saving any code because your macros create functions at each invocation site. And your macro is more complicated than the code it replaces because it has all the syntactic cruft to make it adaptable to the different datatypes and sort orders. Certainly it is easy to make an off by one mistake in a loop like this so there might be some small value there, but I'm not sure the complication is worth that savings for the small number of use points. Particularly because you're not saving any code. -- Philip Pokorny, RHCE Chief Technology Officer PENGUIN COMPUTING, Inc www.penguincomputing.com Changing the world through technical innovation -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@...r.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists