Re: [PATCH/RFC 1/2] lib: string: Remove duplicated function

[Tejun Heo]

Hello,

On Fri, Sep 12, 2014 at 11:01:17AM +0200, Rasmus Villemoes wrote:
> On Fri, Sep 12 2014, Andrew Morton <akpm@xxxxxxxxxxxxxxxxxxxx> wrote:
> 
> > On Wed, 27 Aug 2014 09:36:01 +0200 Rasmus Villemoes <linux@xxxxxxxxxxxxxxxxxx> wrote:
> >> strncasecmp is the POSIX name for this functionality. So rename the
> >> non-broken function to the standard name. To minimize the impact on
> >> the rest of the kernel (and since both are exported to modules), make
> >> strnicmp a wrapper for strncasecmp.

Maybe it's a good idea to convert all existing users of strnicmp()
strncasecmp() and then mark the strnicmp() wrapper as __deprecated for
later removal?

> > I guess it's safe to assume that nobody was depending on the
> > strncasecmp() bug.
> 
> Hm, I thought so as well, but decided to double check. I found one minor
> issue; maybe Tejun can tell if my analysis is correct.
> 
> In drivers/ata/libata-core.c, ata_parse_force_one(), it is not
> immediately clear to me that val cannot end up being the empty
> string. With the buggy strncasecmp, the continue branch is always
> followed (since fp->name is not empty); however, with strncasecmp with
> the correct semantics, the empty string is obviously a prefix of every
> fp->name. So even though the comment says that "1.5" is an ok
> abbreviation of "1.5Gbps", I don't think the intention was to allow ""
> to be an abbreviation of everything. Anyway, the worst that can happen
> seems to be that "ambigious value" [sic] becomes the *reason instead
> of "unknown value".

Sounds right to me and it shouldn't matter at all.

> > Yes, please prepare the strnicmp()->strncasecmp() patches and let's get
> > them merged up.  After a kernel release or two we can zap the
> > back-compat wrapper.

Ooh, somebody already suggested the same. :)

Thanks.

-- 
tejun
--
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/