clang doesn't support this, and says it won't: crypto/hmac.c:57:8: error: fields must have a constant size: 'variable length array in structure' extension will never be supported char ctx[crypto_shash_descsize(hash)]; That part of kernel code should probably be rewritten to not use this, but more and more kernel code seems to turn up that uses this feature of gcc. It used to be only the crypto API, now it is iptables too. Meanwhile I opened this bug to document how to turn off the problematic parts of the kernel, and its dependencies. You need to turn off these: CONFIG_INET_AH CONFIG_INET_ESP CONFIG_INET6_AH CONFIG_INET6_ESP CONFIG_NETFILTER CONFIG_LIBCRC32C The iptables is a problem though, without it we can't really say that "clang builds a Linux kernel". How hard would it be to implement this specific case in clang? And how hard would it be to patch the kernel to not use this feature?
Implementing this would be a crapload of verification work to make sure all the places that handle types handle structs with non-constant size, for handling a few rare constructs like this. Working around this in the kernel would be easy: just replace the struct declaration with some other form of allocation (alloca, kmalloc, etc.).
I agree. This an nested functions are two things we really really don't want to implement.
I have the crypto/hmac an iptables fixes ready and will push them upstream. Hmac should use explicit kmalloc and the hacky iptables macro in fact uses the VLA feature just to compute offset of some struct member which can be simply done by hand. There should be some documentation following why VLA feature should not be used at all, not only because clang does/will not support it, but because it may cause silent memory corruption.
Linux 4.20 kernel is now effectively VLA-free. https://patchwork.kernel.org/patch/10658685/