lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20181222081602.22d42b3e@vmware.local.home>
Date:   Sat, 22 Dec 2018 08:16:02 -0500
From:   Steven Rostedt <rostedt@...dmis.org>
To:     Ingo Molnar <mingo@...nel.org>
Cc:     Linus Torvalds <torvalds@...ux-foundation.org>,
        Linux List Kernel Mailing <linux-kernel@...r.kernel.org>,
        Andrew Morton <akpm@...ux-foundation.org>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        Joe Perches <joe@...ches.com>,
        Namhyung Kim <namhyung@...nel.org>,
        Masami Hiramatsu <mhiramat@...nel.org>,
        Tom Zanussi <zanussi@...nel.org>
Subject: Re: [PATCH v3] string.h: Add str_has_prefix() helper

On Sat, 22 Dec 2018 11:58:45 +0100
Ingo Molnar <mingo@...nel.org> wrote:

> * Steven Rostedt <rostedt@...dmis.org> wrote:
> 
> > On Fri, 21 Dec 2018 16:32:58 -0800
> > Linus Torvalds <torvalds@...ux-foundation.org> wrote:
> >   
> > > On Fri, Dec 21, 2018, 16:06 Steven Rostedt <rostedt@...dmis.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.

I'm working on projects that prefer the second method. But these also
integrate a lot of C++ which using parameters for all I/O is the norm.

> 
> 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.

Like I said, I no longer have a strong preference and I'm happy with
either. It's like going back and forth between Europe and US and using
Celsius or Fahrenheit. There's really no difference in its use (unlike
meters / grams, which have the conversion advantage, temperature is
just a preference).

-- Steve

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ