From: Ingo Molnar <mingo@kernel.org>
To: Steven Rostedt <rostedt@goodmis.org>
Cc: Linus Torvalds <torvalds@linux-foundation.org>,
Linux List Kernel Mailing <linux-kernel@vger.kernel.org>,
Andrew Morton <akpm@linux-foundation.org>,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
Joe Perches <joe@perches.com>, Namhyung Kim <namhyung@kernel.org>,
Masami Hiramatsu <mhiramat@kernel.org>,
Tom Zanussi <zanussi@kernel.org>
Subject: Re: [PATCH v3] string.h: Add str_has_prefix() helper
Date: Sat, 22 Dec 2018 11:58:45 +0100 [thread overview]
Message-ID: <20181222105845.GB130780@gmail.com> (raw)
In-Reply-To: <20181221193711.1571408e@gandalf.local.home>
* Steven Rostedt <rostedt@goodmis.org> wrote:
> On Fri, 21 Dec 2018 16:32:58 -0800
> Linus Torvalds <torvalds@linux-foundation.org> wrote:
>
> > On Fri, Dec 21, 2018, 16:06 Steven Rostedt <rostedt@goodmis.org wrote:
> >
> > > On Fri, 21 Dec 2018 18:13:16
> > >
> > > And I'll make a separate patch that adds:
> > >
> > > static __always_inline bool
> > > str_has_prefix_len(const char *str, const char *prefix, unsigned int *len)
> >
> >
> > Why would this ever be a good idea? What's the advantage over returning the
> > length?
>
> Style?
>
> I was just thinking that some people (like Joe) think it's in bad taste
> to have:
>
> if ((len = str_has_prefix(str, "const"))) {
>
> and it might look better to have:
>
> if (str_has_prefix_len(str, "const", &len)) {
>
> Honestly, I'm good with either and don't really have a preference.
The first one is infinitely more readable and less ambiguous than a
random series of arguments with unknown semantics for 'len': does 'len'
have to be pre-initialized or does it always get set by the function, is
the 'len' return always the same as the str_has_prefix_len() return value
or is it a separate error code, etc.
I have no idea in what universe it's preferrable to pass it as an
argument to a function.
We only punt return parameters to arguments when we are *forced* to,
because there's too many of them, or there's some separate error and
value path that cannot be encoded via any of the well-known pointer or
integer encodings of errors, etc.
Thanks,
Ingo
next prev parent reply other threads:[~2018-12-22 18:19 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-12-21 23:13 [PATCH v3] string.h: Add str_has_prefix() helper Steven Rostedt
2018-12-21 23:19 ` Joe Perches
2018-12-21 23:25 ` Steven Rostedt
2018-12-21 23:38 ` Steven Rostedt
2018-12-22 9:28 ` Namhyung Kim
2018-12-22 12:22 ` Steven Rostedt
2018-12-23 3:23 ` Namhyung Kim
2018-12-21 23:44 ` Joe Perches
2018-12-22 0:00 ` Steven Rostedt
2018-12-22 0:06 ` Steven Rostedt
2018-12-22 0:22 ` Joe Perches
[not found] ` <CAHk-=wgfSR9qhEWf--Do11jUFHyVM+VEmwm5LBS2JsV0F5yakw@mail.gmail.com>
2018-12-22 0:37 ` Steven Rostedt
2018-12-22 10:58 ` Ingo Molnar [this message]
2018-12-22 13:16 ` Steven Rostedt
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20181222105845.GB130780@gmail.com \
--to=mingo@kernel.org \
--cc=akpm@linux-foundation.org \
--cc=gregkh@linuxfoundation.org \
--cc=joe@perches.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mhiramat@kernel.org \
--cc=namhyung@kernel.org \
--cc=rostedt@goodmis.org \
--cc=torvalds@linux-foundation.org \
--cc=zanussi@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.