4 ms·
Curious that there isn't a static analysis to verify that these have been removed completely. Is this difficult or was it just not worth the effort?
by ericpauley 8y ago
Curious that there isn't a static analysis to verify that these have been removed completely. Is this difficult or was it just not worth the effort?
- kbumsik 8y agoI think VLA becomes a compiler feature. We can disable VLA using a GCC option flag: -Werror=vla. So it should be quite easy to detect if VLA is used in the source.
- bonyt 8y agoI think they mean it’s removed for most of the modules in the kernel and therefore the ones that may be lurking about still aren’t being compiled on most configurations. According to the article, “there may be a couple more VLAs hiding in hard-to-find randconfigs.”
- ndesaulniers 8y agoThe hard part with the kernel is its fanciful build system, Kbuild. It's great at turning off compilation of subsystems that you don't plan to use. The difficulty is that there are a large number of mutually exclusive number of configurations, so the config that's called `allyesconfig` really isn't "all" because you can only pick one of the mutually exclusive configs. Additionally, some configs don't just add/remove code, but can change which implementation gets compiled in (all via C preprocessor and -D flags). Those configs mean there are massive combinations of what is actually set, and which code you're actually trying to compile. I imagine that's similarly difficult for static analysis; due to the build system and what code you run it over. I think a simpler approach with grep might actually work better.