RE: Variant tests failing on big endian machines
- From: "Williams, James P2" <james p2 williams lmco com>
- To: "'Rafael dos Santos'" <rdossant redhat com>, Torsten Schoenfeld <kaffeetisch gmx de>
- Cc: "gtk-perl-list gnome org" <gtk-perl-list gnome org>
- Subject: RE: Variant tests failing on big endian machines
- Date: Fri, 26 Jun 2015 16:09:15 +0000
----- Original Message -----
From: "Torsten Schoenfeld" <kaffeetisch gmx de>
To: gtk-perl-list gnome org
Sent: Friday, 26 June, 2015 3:34:48 PM
Subject: Re: Variant tests failing on big endian machines
I found the culprit. On the GVariant.xs file, we have:
const char * g_variant_classify (GVariant *value);
PREINIT:
GVariantClass vclass;
CODE:
vclass = g_variant_classify (value);
RETVAL = (const char *) &vclass;
OUTPUT:
RETVAL
The RETVAL value will be arch-dependent because of the way it's
accessed.
I'm not familiar with .xs syntax, so what's the way to deal with
endianness on this type of files?
Does this work?
const char * g_variant_classify (GVariant *value);
PREINIT:
GVariantClass vclass;
CODE:
vclass = g_variant_classify (value);
RETVAL = (const char *) &((char) vclass);
GVariant.xs: In function ‘XS_Glib__Variant_classify’:
GVariant.xs:285:26: error: lvalue required as unary ‘&’ operand
RETVAL = (const char *) &((char) vclass);
^
Makefile:468: recipe for target 'GVariant.o' failed
make: *** [GVariant.o] Error 1
Unfortunately, casting it to char makes it an rvalue which doesn't have
an address.
The first version returns the address of a local variable, which will be invalid after control flow leaves
the scope. I don't know the code enough to suggest an alternative. Doesn't the typemap entry for const char
* assume it's a null-terminated string, and try to convert it to a Perl string? I'd think you'd need some
other return type if you're returning the address of something exotic.
Jim
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]