Hi Kaz,

Many thanks for your comments on the test code.

Actually it is not the test case used in our project but just to verify
whether it works good as expected.
The test code (already merged to the libffi tests at
https://github.com/libffi/libffi/pull/640 as requested by them) was
identified as a bug specific to x86_64 which will be investigated to see
what happens.


Thanks and Best Regards
Cheng Jin




From:	"Kaz Kylheku (libffi)" <382-725-6798@kylheku.com>
To:	Cheng Jin <jincheng@ca.ibm.com>
Cc:	libffi-discuss@sourceware.org
Date:	2021-06-09 07:48 PM
Subject:	[EXTERNAL] Re: Incorrect data detected in the nested float
            struct with  x86/libffi on Linux/64bit



On 2021-06-09 09:41, Cheng Jin via Libffi-discuss wrote:
> Hi,

Hi Cheng Jin,

A small matter on a tangent.

>
> 		   cls_struct_fields1[0] = &ffi_type_float;
> 		   cls_struct_fields1[1] = &cls_struct_type2;
> 		   cls_struct_fields1[2] = NULL;

Indeed, the array describing the element types of a structure must be
null terminated, so this is required.

> 		   cls_struct_type1.size = 0;
> 		   cls_struct_type1.alignment = 0;
> 		   cls_struct_type1.type = FFI_TYPE_STRUCT;
> 		   cls_struct_type1.elements = cls_struct_fields1;

Note that here, the size of the object is not indicated. That's why
the extra null pointer is required to infer the size.

>
> 		   dbl_arg_types[0] = &ffi_type_float;
> 		   dbl_arg_types[1] = &cls_struct_type1;
> 		   dbl_arg_types[2] = NULL;

But, for the argument array of a ffi_cif, no null termination is
required.

> 		  ffi_prep_cif(&cif_temp, FFI_DEFAULT_ABI, 2, retType,
dbl_arg_types);

No requirement for a null terminator is documented or appears in
examples. The 2 argument indicates the number of elements.

There is no harm in it; just pointing it out.

When I looked at your code, I went scrambling through documentation
to see if I was missing a required null terminator. :)

Cheers ...