Messages in this thread | ![/](/images/icornerl.gif) | | Date | Sat, 22 Dec 2018 11:58:45 +0100 | From | Ingo Molnar <> | Subject | Re: [PATCH v3] string.h: Add str_has_prefix() helper |
| |
* 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
| ![\](/images/icornerr.gif) |