[PATCH] add stricmp

[PATCH] add stricmp

[Jan Beulich]

[-- Attachment #1: Type: text/plain, Size: 1628 bytes --]

(Note: Patch also attached because the inline version is certain to get
line wrapped.)

While strnicmp existed in the set of string support routines, stricmp
didn't, which this patch adjusts.

Signed-off-by: Jan Beulich <jbeulich@novell.com>

diff -Npru 2.6.13/include/linux/string.h
2.6.13-stricmp/include/linux/string.h
--- 2.6.13/include/linux/string.h	2005-08-29 01:41:01.000000000
+0200
+++ 2.6.13-stricmp/include/linux/string.h	2005-09-01
11:32:12.000000000 +0200
@@ -47,6 +47,9 @@ extern int strcmp(const char *,const cha
 #ifndef __HAVE_ARCH_STRNCMP
 extern int strncmp(const char *,const char *,__kernel_size_t);
 #endif
+#ifndef __HAVE_ARCH_STRICMP
+extern int stricmp(const char *, const char *);
+#endif
 #ifndef __HAVE_ARCH_STRNICMP
 extern int strnicmp(const char *, const char *, __kernel_size_t);
 #endif
diff -Npru 2.6.13/lib/string.c 2.6.13-stricmp/lib/string.c
--- 2.6.13/lib/string.c	2005-08-29 01:41:01.000000000 +0200
+++ 2.6.13-stricmp/lib/string.c	2005-09-01 11:32:13.000000000
+0200
@@ -24,6 +24,31 @@
 #include <linux/ctype.h>
 #include <linux/module.h>
 
+#ifndef __HAVE_ARCH_STRICMP
+/**
+ * stricmp - Compare two strings case-insensitively
+ * @s1: One string
+ * @s2: Another string
+ */
+int stricmp(const char *s1, const char *s2)
+{
+	unsigned char c1, c2;
+
+	for (;;) {
+		c1 = *s1++;
+		c2 = *s2++;
+		if (!c1 || !c2)
+			break;
+		if (c1 == c2)
+			continue;
+		if ((c1 = tolower(c1)) != (c2 = tolower(c2)))
+			break;
+	}
+	return (int)c1 - (int)c2;
+}
+#endif
+EXPORT_SYMBOL(stricmp);
+
 #ifndef __HAVE_ARCH_STRNICMP
 /**
  * strnicmp - Case insensitive, length-limited string comparison


[-- Attachment #2: linux-2.6.13-stricmp.patch --]
[-- Type: application/octet-stream, Size: 1627 bytes --]

(Note: Patch also attached because the inline version is certain to get
line wrapped.)

While strnicmp existed in the set of string support routines, stricmp
didn't, which this patch adjusts.

Signed-off-by: Jan Beulich <jbeulich@novell.com>

diff -Npru 2.6.13/include/linux/string.h 2.6.13-stricmp/include/linux/string.h
--- 2.6.13/include/linux/string.h	2005-08-29 01:41:01.000000000 +0200
+++ 2.6.13-stricmp/include/linux/string.h	2005-09-01 11:32:12.000000000 +0200
@@ -47,6 +47,9 @@ extern int strcmp(const char *,const cha
 #ifndef __HAVE_ARCH_STRNCMP
 extern int strncmp(const char *,const char *,__kernel_size_t);
 #endif
+#ifndef __HAVE_ARCH_STRICMP
+extern int stricmp(const char *, const char *);
+#endif
 #ifndef __HAVE_ARCH_STRNICMP
 extern int strnicmp(const char *, const char *, __kernel_size_t);
 #endif
diff -Npru 2.6.13/lib/string.c 2.6.13-stricmp/lib/string.c
--- 2.6.13/lib/string.c	2005-08-29 01:41:01.000000000 +0200
+++ 2.6.13-stricmp/lib/string.c	2005-09-01 11:32:13.000000000 +0200
@@ -24,6 +24,31 @@
 #include <linux/ctype.h>
 #include <linux/module.h>
 
+#ifndef __HAVE_ARCH_STRICMP
+/**
+ * stricmp - Compare two strings case-insensitively
+ * @s1: One string
+ * @s2: Another string
+ */
+int stricmp(const char *s1, const char *s2)
+{
+	unsigned char c1, c2;
+
+	for (;;) {
+		c1 = *s1++;
+		c2 = *s2++;
+		if (!c1 || !c2)
+			break;
+		if (c1 == c2)
+			continue;
+		if ((c1 = tolower(c1)) != (c2 = tolower(c2)))
+			break;
+	}
+	return (int)c1 - (int)c2;
+}
+#endif
+EXPORT_SYMBOL(stricmp);
+
 #ifndef __HAVE_ARCH_STRNICMP
 /**
  * strnicmp - Case insensitive, length-limited string comparison

Re: [PATCH] add stricmp

[Christoph Hellwig]

On Thu, Sep 08, 2005 at 05:05:06PM +0200, Jan Beulich wrote:
> (Note: Patch also attached because the inline version is certain to get
> line wrapped.)
> 
> While strnicmp existed in the set of string support routines, stricmp
> didn't, which this patch adjusts.

I don't thing we should do case-insenstitive comparims in kernel, and
in the few cases where we must (legacy OS fileystem support) it needs
to be NLS-capable.

But once again we need to see the users anyway.  You're adding tons of
bloat in your patches without showing us an actually useful user.

Re: [PATCH] add stricmp

[Jan Beulich]

>>> Christoph Hellwig <hch@infradead.org> 08.09.05 17:17:54 >>>
>On Thu, Sep 08, 2005 at 05:05:06PM +0200, Jan Beulich wrote:
>> (Note: Patch also attached because the inline version is certain to
get
>> line wrapped.)
>> 
>> While strnicmp existed in the set of string support routines,
stricmp
>> didn't, which this patch adjusts.
>
>I don't thing we should do case-insenstitive comparims in kernel, and
>in the few cases where we must (legacy OS fileystem support) it needs
>to be NLS-capable.

Then how am I supposed to do ASCII-only case-insensitive compares (i.e.
reading config files)? And why is there a strnicmp? If this is not going
to be available as general library routine, I'd just have to add this to
a place where it doesn't really belong.

>But once again we need to see the users anyway.  You're adding tons
of
>bloat in your patches without showing us an actually useful user.

The intended user can be seen at
http://forge.novell.com/modules/xfmod/project/?nlkd (and see also my
previous reply to your earlier, similar complaint).

Jan

Re: [PATCH] add stricmp

[Christoph Hellwig]

On Thu, Sep 08, 2005 at 05:28:19PM +0200, Jan Beulich wrote:
> Then how am I supposed to do ASCII-only case-insensitive compares (i.e.
> reading config files)?

You're not supposed to read config files in the kernel, nevermind
case-insensitive ones.  If you want things case-insensitive please stay in
the DOS world, thanks.

> The intended user can be seen at
> http://forge.novell.com/modules/xfmod/project/?nlkd (and see also my
> previous reply to your earlier, similar complaint).

That's not a useful user.  It's a big mess that should stay away from the
kernel as far as possible.

Re: [PATCH] add stricmp

[Alan Cox]

On Iau, 2005-09-08 at 17:28 +0200, Jan Beulich wrote:
> Then how am I supposed to do ASCII-only case-insensitive compares (i.e.
> reading config files)? And why is there a strnicmp? If this is not going

There is no such thing as "ascii" for case sensitivity. The case and
ordering rules are locale not symbol set based and they also depend
totally on the exact semantics of whatever legacy technology you are
interfacing with. I assume you mean "C locale, ascii character set",
which limits your debugger to speaking a subset of American English (no
café or naïve 8))

Any routine of that nature belongs in the user environment to which it
applies, and should be used with care, and preferably pushed to user
space or to a user app on the debug hosting box as kgdb does.

The only general, usable strnicmp safe for general kernel use would be a
full all singing all dancing UTF-8 symbol aware arbitary locale
implementation. And that we *definitely* do not want in kernel.

Alan

Re: [PATCH] add stricmp

[Jan Beulich]

>The only general, usable strnicmp safe for general kernel use would be
a
>full all singing all dancing UTF-8 symbol aware arbitary locale
>implementation. And that we *definitely* do not want in kernel.

Then you'd want to immediately get rid of the mentioned, pre-exisiting
strnicmp().

Jan

Re: [PATCH] add stricmp

[Alan Cox]

On Iau, 2005-09-08 at 17:45 +0200, Jan Beulich wrote:
> >The only general, usable strnicmp safe for general kernel use would be
> a
> >full all singing all dancing UTF-8 symbol aware arbitary locale
> >implementation. And that we *definitely* do not want in kernel.
> 
> Then you'd want to immediately get rid of the mentioned, pre-exisiting
> strnicmp().

Yes

Re: [PATCH] add stricmp

[viro]

On Thu, Sep 08, 2005 at 05:37:13PM +0100, Alan Cox wrote:
> On Iau, 2005-09-08 at 17:45 +0200, Jan Beulich wrote:
> > >The only general, usable strnicmp safe for general kernel use would be
> > a
> > >full all singing all dancing UTF-8 symbol aware arbitary locale
> > >implementation. And that we *definitely* do not want in kernel.
> > 
> > Then you'd want to immediately get rid of the mentioned, pre-exisiting
> > strnicmp().
> 
> Yes

There is a couple of legitimate uses of that one - mostly in workarounds for
bugs in unrelated programs...  Most of the strnicmp() users should go, though.