Julius Werner has posted comments on this change. ( https://review.coreboot.org/c/coreboot/+/32023 )
Change subject: src/arch: Use 'include <stdlib.h>' when appropriate ......................................................................
Patch Set 29:
I think it's helpful for having portable code for testing purposes if we can isolate the environment more easily.
Is <types.h> a problem for that? It's just a normal coreboot header that chain-includes those others. If you somehow mock out the coreboot versions of <stddef.h> and <stdint.h> for others specific to the test environment, that shouldn't cause a problem... your test code can still include coreboot's <types.h> which will then chain-include those test headers.
Personally, I feel the POSIX distinctions are really annoying sometimes (e.g. why are size_t and uintptr_t in different headers?), and I think having a catchall "include all the standard type and helper stuff" header is nice to avoid forcing everyone to deal with that all the time, while still allowing stuff to be defined in the appropriate POSIX headers in a chain-include behind that. I think in fact this pattern can help making the kind of test isolation you describe easier... right now we have the problem that our <stdXXX.h> headers do *more* than defined by POSIX (e.g. including <commonlib/helpers.h> and defining a bunch of coreboot-specific macros), which would cause things to break if you tried to switch those out for headers from a test environment. If we are piping #includes from most files through an intermediate non-POSIX header like <types.h>, that would make it easier to move those non-POSIX components out of the standard headers and into <types.h> to fix those issues without having to touch every file again and again.