RE: Variant tests failing on big endian machines

["Williams, James P2" <james p2 williams lmco com>]

> ----- 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