John Martin wrote:
> Ali Bahrami wrote:
>>
>>
>> I believe that the root cause of this problem can be
>> traced to the behavior of g_utf8_validate(). Consider the
>> following test program:
>>
>>
>> #include "stdio.h"
>> #include "glib.h"
>>
>> int main(int argc, char **argv)
>> {
>> printf("validate %d\n", g_utf8_validate("File", -1,
>> NULL));
>> return (0);
>> }
>>
>> The constant string "File" is valid UTF8, so g_utf8_validate()
>> should report True (1). And it does, when built as 32-bit X86
>> code, or as either 32 or 64-bit code on sparc. On amd64
>> however:
>>
>> % gcc -m64 -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include
>> gtk_test.c -lglib-2.0
>> % ./a.out
>> validate 0
> Pass the actual string length as a workaround:
>
> $ cat gtk_test.c
> #include "stdio.h"
> #include "glib.h"
>
> int
> main(int argc, char *argv[], char *envp[])
> {
> printf("validate %d\n", g_utf8_validate("File", -1, NULL));
> printf("validate %d\n", g_utf8_validate("File", strlen("File"),
> NULL));
> return (0);
> }
> $ gcc -m64 -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include
> gtk_test.c -lglib-2.0
> $ ./a.out
> validate 0
> validate 1
>
> There is probably a bug in the library when compiled for 64 bit mode for
> determining if the second argument is a positive or negative number.
>
>
>
Wonderful, 64-bit emacs-gtk with that change works!
Should I file a CR (and do you know the category for it)?
Thanks...
- Ali
