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.
Not a huge problem. As I noted, reducing dependencies is the more important bit. If one can write portable code there's not as much of an issue.
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.
Whether we agree with posix or not issue I was bringing up. It's a portable target environment that our libraries and code can then be easily compiled for multiple environments. Yes, we can totally provide a single binding header that adapts to the environment. I was just noting how I think it's helpful to have code that can be easily reused.
To view, visit change 32023. To unsubscribe, or for help writing mail filters, visit settings.