diff options
author | Kaz Kylheku <kaz@kylheku.com> | 2022-05-18 08:10:50 -0700 |
---|---|---|
committer | Kaz Kylheku <kaz@kylheku.com> | 2022-05-18 08:10:50 -0700 |
commit | abcd7ee5c09d7fbd26410b6f880e5534b0bbb51a (patch) | |
tree | b8b754b8a5e38044892f785a13722ae750fdb487 /tests/017/glob-zarray.tl | |
parent | e3f1adc4014641223ab3f5697e550439e10ddca8 (diff) | |
download | txr-abcd7ee5c09d7fbd26410b6f880e5534b0bbb51a.tar.gz txr-abcd7ee5c09d7fbd26410b6f880e5534b0bbb51a.tar.bz2 txr-abcd7ee5c09d7fbd26410b6f880e5534b0bbb51a.zip |
ffi: alignment bug in undimensioned arrays.
Because the varray behavior for undimensioned arrays was introduced
in dubious commit 7880c9b565ab438e1bf0250a967acdbf8d04cb42
in 2017, which used make_ffi_type_pointer to register the type,
claiming that the C representation is pointer (which was not true
in that commit, nor ever since).
As a result, though, undimensioned arrays received the alignment
of pointers, rather than deriving it from the element type.
Thus (array char) has 4 or 8 byte alignment whereas (array 4 char)
correctly has 1 byte alignment.
* ffi.c (ffi_type_compile): Use make_ffi_type_array for the two-element
array syntax, just like for the dimensioned case with three elements.
Then override some of the functions with the varray versions.
* tests/017/ffi-misc.tl: Fix the test case which exposed this.
In the type (struct flex (a char) (b (zarray char)), the array
b must be at offset 1. I didn't notice that the offset of 4
being confirmed by the test case was wrong, but this showed up
when running the test case on a platform with 8 byte pointers.
Diffstat (limited to 'tests/017/glob-zarray.tl')
0 files changed, 0 insertions, 0 deletions