re: Conflict between system and compiler types

[matthew green <mrg%eterna.com.au@localhost>]

Christos Zoulas writes:
> In article <f87d8d38-ca50-7cb5-0716-4f894070fa0d%gmx.com@localhost>,
> Kamil Rytarowski  <n54%gmx.com@localhost> wrote:
> >
> >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?
> 
> It is not as simple as that. We have c++ to thank for that and the
> encoding of types in function name mangling. For example there are
> 32 bit architectures where size_t is unsigned int and not unsigned
> long and they need to be handled specially. I think that the best
> way is to do it gradually and handle the easy ones first...

i'm fairly sure this is already correct because you get compiler
warnings if you don't do it properly.  don't you recall when we
made sparc use 'long' for a bunch of things so it would be the
same as sparc64? :)  we had build failures reported for ages..

i'm not worried about this proposal.  the only request i have is
to ensure that all existing header paths continue to work (ie,
machine/ansi.h should continue to publish the same things, even
if it is no longer the source of truth.)


.mrg.