Re: Conflict between system and compiler types

[Christos Zoulas <christos%zoulas.com@localhost>]

> On Feb 4, 2019, at 3:23 PM, matthew green <mrg%eterna.com.au@localhost> wrote:
> 
> 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.)

That's exactly what I remember :-) Plus the "long long" vs "long"...
I am afraid that if we provide "backup" values in case the provider
ones are not available, these might need ifdefs...

christos