I'm currently using 0.8.0-dev.2192+65d279bc0 if that matters.
Problem:
I'd like to use these C structs from ACPICA in my Zig code. The following code is generated from it:
// (...)/actypes.h:1382:37: warning: struct demoted to opaque type - has variable length array
pub const struct_acpi_pnp_device_id_list = opaque {};
pub const ACPI_PNP_DEVICE_ID_LIST = struct_acpi_pnp_device_id_list;
pub const struct_acpi_device_info = extern struct {
// ... fields that aren't important ..
CompatibleIdList: ACPI_PNP_DEVICE_ID_LIST,
};
pub const ACPI_DEVICE_INFO = struct_acpi_device_info;
The warning seemed fair by itself when I first looked at this, but this apparently means that I can't use ACPI_DEVICE_INFO/struct_acpi_device_info at all:
./zig-cache/o/3016e146699c4abaeedfebe9c82141cf/cimport.zig:153:5: error: opaque types have unknown size and therefore cannot be directly embedded in structs
CompatibleIdList: ACPI_PNP_DEVICE_ID_LIST,
^
Having a variable amount of data at the end of a data structure seems like a common pattern in data structures dealing with hardware. I've had to write code like this here for USB EHCI, among other places to access this kind of data from hardware. I'm fine writing code like that and it seems like I'm not the first person writing Zig to do so: #6008.
Possible Solutions?
I'm wondering if, for the sake of better compatibility with C, Zig could only demote the variable length array field itself to an opaque type and allow them at the end of the struct. This would mirror how VLAs act in C. It might also make previously mentioned situation of using this in normal Zig more readable and reduce the amount of pointer arithmetic, but I think that's a minor advantage if it's one at all. Or maybe this should just should be limited to extern structs if it is better to isolate this behavior?
const MyType = extern struct {
length: usize,
data: opaque {},
};
Alternatively it would be better from my perspective as a user if Zig fully supported VLAs in structs, but I'm assuming that's not on the table because normal VLAs have been shot down before: #3952.
Also
The actual cimport.zig lines with the warning are:
pub const ACPI_PNP_DEVICE_ID = struct_acpi_pnp_device_id; // /data/development/os/georgios/kernel/platform/acpica/acpica/source/include/actypes.h:1382:37: warning: struct demoted to opaque type - has variable length array
pub const struct_acpi_pnp_device_id_list = opaque {};
It's kinda weird the comment is following ACPI_PNP_DEVICE_ID, shouldn't there be a newline there or it should be following struct_acpi_pnp_device_id_list, which is what it's actually talking about?
I'm currently using 0.8.0-dev.2192+65d279bc0 if that matters.
Problem:
I'd like to use these C structs from ACPICA in my Zig code. The following code is generated from it:
The warning seemed fair by itself when I first looked at this, but this apparently means that I can't use
ACPI_DEVICE_INFO/struct_acpi_device_infoat all:Having a variable amount of data at the end of a data structure seems like a common pattern in data structures dealing with hardware. I've had to write code like this here for USB EHCI, among other places to access this kind of data from hardware. I'm fine writing code like that and it seems like I'm not the first person writing Zig to do so: #6008.
Possible Solutions?
I'm wondering if, for the sake of better compatibility with C, Zig could only demote the variable length array field itself to an opaque type and allow them at the end of the struct. This would mirror how VLAs act in C. It might also make previously mentioned situation of using this in normal Zig more readable and reduce the amount of pointer arithmetic, but I think that's a minor advantage if it's one at all. Or maybe this should just should be limited to
extern structs if it is better to isolate this behavior?Alternatively it would be better from my perspective as a user if Zig fully supported VLAs in structs, but I'm assuming that's not on the table because normal VLAs have been shot down before: #3952.
Also
The actual
cimport.ziglines with the warning are:It's kinda weird the comment is following
ACPI_PNP_DEVICE_ID, shouldn't there be a newline there or it should be followingstruct_acpi_pnp_device_id_list, which is what it's actually talking about?