Re: [patch 00/11] Hardware Breakpoint interfaces

[Ingo Molnar <mingo@elte.hu>]

* 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