Re: [RFC PATCH 3/3a] ptrace: add _ptrace_may_access()

[Ingo Molnar]

* Roland McGrath <roland@xxxxxxxxxx> wrote:

> > Something like the patch below allows the reuse of the locked 
> > version of __ptrace_may_access and pushes the int->bool 
> > conversion into an inline.
> 
> I think it would be cleaner and safe/simple enough to invert the 
> public ptrace_may_access() to just return the int and invert the ! 
> on all the callers (all one in fs/proc/task_mmu.c and all four in 
> fs/proc/base.c).

hm, i considered that briefly and rejected the idea because 
something that says 'may' in its name is generally assumed to be a 
logic function-ish thing.

I.e. in such case: ptrace_may_access() or task_is_traced() people 
sub-consciously assume that 0 means "no", non-0 means "yes". So in 
that sense i liked the bool wrapper and preserved that in the 
inline.

We do have the retval==0-means-success convention in a number of 
APIs, but APIs that include a verb in their names assert some sort 
of property all have bool behavior.

(The underscore itself signals some special property - so there the 
deviation from the usual conventions isnt a big problem.)

This might sound like a nuance, but it really matters in the grand 
scheme of things. So IMHO inverting the logic is a step backwards - 
beyond the needless churn as well that it causes in various 
subsystems.

	Ingo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/