On 04.02.2019 08:46, matthew green wrote: > Martin Husemann writes: >> On Mon, Feb 04, 2019 at 05:52:28AM +0000, David Holland wrote: >>> They are wrong -- the system ABI is the OS's responsibility >>> (including, possibly, compat obligations that the compiler folks don't >>> know about and shouldn't have to care about) because it's the OS that >>> provides the libraries that the definitions in the system ABI headers >>> are supposed to match. >> >> True, but in this case the compiler has been instructed to compile for >> a different ABI, and we may well consider to have our own provided types >> being flexible to cope (if it comes at basically no cost). > > indeed. we work to keep the compiler and base types the same > and when they change, it can be a pain, even if the change is > not a change in ABI. eg, when we added sparc64, we changed > some sparc types from 'int' to 'long' so that the would size > themselves properly, but this triggered warnings when people > had not updated their base headers and compiler at the same > time (eg, building a new kernel.) > > as i understand Kamil's idea, and as we've been using in some > ports already for a while, is to let the compiler builtins > provide these in our headers, and i think that is a fine > idea and we can even use it to eliminate the MD headers from > providing these definitions at all (though it would be best > to make sure they continue to do so -- but by having them > include the MI header, instead of the current opposite.) > We already maintain types in compilers (Clang, GCC) and we could rely on them directly. I've checked that the following types are in GCC, TinyCC, Clang/LLVM, PCC: __WCHAR_TYPE__ __SIZE_TYPE__ __WINT_TYPE__ __PTRDIFF_TYPE__ The bar for a compiler using our native headers is already higher than that so this doesn't change anything. It's a stronger proposal but we could require these types and remove entirely homegrown redefinitions and maintain the types directly in compilers. There is already a header using the compiler builtins. https://nxr.netbsd.org/xref/src/sys/sys/common_ansi.h#65 OR1K and RISCV use them from the start. So the current proposal is to replace all src/sys/arch/*/include/ansi.h with a single include of sys/common_ansi.h, analogously to RICCV and OR1K. What do you think? > > .mrg. >
Attachment:
signature.asc
Description: OpenPGP digital signature