On Thu, Jul 27, 2000 at 10:35:40AM -0700, Guy Harris wrote:
> > I think we should rely on glib and use in Ethereal the g_str* functions.
>
> I seem to remember a message to one of the GTK+ mailing lists suggesting
> that one cannot rely on "g_strcasecmp()" and "g_strncasecmp()", i.e.
> there was a message reporting a bug in those routines.
>
> My GTK+ mailing list archives are at home, so I'd either have to wait
> until I get home or dredge through the archives on the GNOME Web site to
> see what the precise problem is.
Here it is - it suggests that we should *not* rely on "g_strncasecmp()".
"g_strcasecmp()", however, is OK.
From: Tor Lillqvist <tml@xxxxxx>
Date: Thu, 6 Jul 2000 00:06:51 +0300 (FLE Daylight Time)
To: gtk-devel-list@xxxxxxxxx
Subject: Bug in strncasecmp routine (glib source)
Forwarded from gimpwin-users:
From: Jean-Louis HAMEL <jlhamel@xxxxxxxxxxxxxxxx>
To: gimpwin-users@xxxxxxxxxxx
Subject: [gimpwin-users] Bug in strncasecmp routine (glib source)
Date: Wed, 05 Jul 2000 21:54:31 +0200
Hi,
I have found a bug in the routine "strncasecmp()" which stays in the
file "gstrfuncs.c" from the glib stuff. It affects the Windows version
and some Unix lacking of a native version of this routine.
Here is a part of this routine:
while (n-- && *s1 && *s2)
{
/* According to A. Cox, some platforms have islower's that
* don't work right on non-uppercase
*/
c1 = isupper ((guchar)*s1) ? tolower ((guchar)*s1) : *s1;
c2 = isupper ((guchar)*s2) ? tolower ((guchar)*s2) : *s2;
if (c1 != c2)
return (c1 - c2);
s1++; s2++;
}
if (n) /* <============= WRONG, should be if(++n) */
return (((gint)(guchar) *s1) - ((gint)(guchar) *s2));
else
return 0;
If the while loop exits on n = 0, n is postdecremented and takes the -1
value, and the test "if (n)" does not not work correctly, leading to a
wrong result. As an example:
strncasecmp("AB", "ABC", 2)
gives a non null result.
Correction: replace "if(n)" by "if(++n)".
The correction should be applied soon, since this bug produces errors
difficult to find...
I have found this bug when, after having successfully compiled the
guash-2.2.3 plugin (from the TML's source snapshot), I tried to
understand why this guash version attempted always to rebuild all the
thumbnails, even when they already existed. Looking at the program
source, I found that this behavior came from a wrong result of an
strncasecmp() call.
JLH
_______________________________________________
gtk-devel-list mailing list
gtk-devel-list@xxxxxxxxx
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
From: Tim Janik <timj@xxxxxxx>
Date: Sat, 15 Jul 2000 09:17:17 +0200 (CEST)
To: Jean-Louis HAMEL <jlhamel@xxxxxxxxxxxxxxxx>
Cc: gtk-devel-list@xxxxxxxxx
Subject: Re: Bug in strncasecmp routine (glib source)
On Thu, 6 Jul 2000, Tor Lillqvist wrote:
> I have found a bug in the routine "strncasecmp()" which stays in the
> file "gstrfuncs.c" from the glib stuff. It affects the Windows version
> and some Unix lacking of a native version of this routine.
>
> Here is a part of this routine:
>
> while (n-- && *s1 && *s2)
> {
> /* According to A. Cox, some platforms have islower's that
> * don't work right on non-uppercase
> */
> c1 = isupper ((guchar)*s1) ? tolower ((guchar)*s1) : *s1;
> c2 = isupper ((guchar)*s2) ? tolower ((guchar)*s2) : *s2;
> if (c1 != c2)
> return (c1 - c2);
> s1++; s2++;
> }
> if (n) /* <============= WRONG, should be if(++n) */
> return (((gint)(guchar) *s1) - ((gint)(guchar) *s2));
> else
> return 0;
thanks, fixed by moving the decrement of n into the loop body.
>
> JLH
>
---
ciaoTJ
_______________________________________________
gtk-devel-list mailing list
gtk-devel-list@xxxxxxxxx
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
