Re: [patch 00/11] Hardware Breakpoint interfaces

Ingo Molnar
2009-03-10T14:55:26Z

* Alan Stern <stern@rowland.harvard.edu> wrote:

> On Tue, 10 Mar 2009, Ingo Molnar wrote:
>
> >
> > There's also a few checkpatch warnings that need to be
> > addressed:
> >
> > ERROR: do not use assignment in if condition
> > #1084: FILE: arch/x86/kernel/ptrace.c:581:
> > + else if ((thbi = alloc_thread_hw_breakpoint(tsk)) ==
> > NULL)
>
> Changing this to remove the assignment from within the "if"
> condition would make the code less readable, not more. [...]

It's not just about basic readability. We dont do assignmets
like that because it's very easy to miss them (and their side
effects) and conflating them with '=='.

It's part of a long
> series of tests; in schematic form:
>
> if (n == 4 || n == 5)
> ...
> else if (n == 6) {
> ...
> }
> else if (!tsk->thread.hw_breakpoint_info && val == 0)
> ...
> else if ((thbi = alloc_thread_hw_breakpoint(tsk)) == NULL)
> ...
> else if (n < HB_NUM) {
> ...
> }
> else
> ...
>
> If you can suggest a way to change the code without making it
> worse, I'm sure Prasad will be happy to adopt it.

The obvious solution which we use in many other places in
arch/x86 is to split out that butt-ugly if else if else if else
maze into a helper inline function that does:

if (n == 4 || n == 5) {
do stuff;
return;
}

if (n == 6) {
do stuff;
return;
}

if (!tsk->thread.hw_breakpoint_info && val == 0) {
do stuff;
return;
}

thbi = alloc_thread_hw_breakpoint(tsk);

if (!tbhi)
...

Ingo