[lkml]   [2009]   [May]   [7]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [RFC PATCH 3/3a] ptrace: add _ptrace_may_access()

* Roland McGrath <> 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

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


 \ /
  Last update: 2009-05-07 10:21    [W:0.166 / U:1.448 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site