Hello, On Fri, Sep 12, 2014 at 11:01:17AM +0200, Rasmus Villemoes wrote: > On Fri, Sep 12 2014, Andrew Morton <a...@linux-foundation.org> wrote: > > > On Wed, 27 Aug 2014 09:36:01 +0200 Rasmus Villemoes > > <li...@rasmusvillemoes.dk> 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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/