Re: [Qemu-devel] [PATCH v5 04/10] softfloat: Drop [u]int16 types in favor of [u]int_fast16_t

[Peter Maydell]

On 7 March 2011 23:37, Aurelien Jarno <address@hidden> wrote:
> I understand your point, but OTOH int_fast16_t means at least int16_t so
> in practice it doesn't bring anything more than changing to int16_t,
> except more pain as the size actually depends on the host.

But at the moment we implement int16 as int, so (a) we'd be telling
the compiler it needed to use a type that was (fractionally) less
efficient and (b) we already know that the code can cope with the
type being wider than 16 bits, because that's how we're compiling
the code today. The thing we should be worrying about is that maybe
there's code that accidentally requires more than 16 bits in an
int16 which would break if you defined it as an int16_t...

> If we want to change the int here, we should either use int32_t here
> (which matches the size of int), or just look case by case and use the
> correct type.

Correct choice between 'bits16' and 'uint16' is actually one of
the areas where I pretty much trust the original softfloat code:
I think it's definitely a retrograde step to throw that away,
and personally I would NAK any patch which merges the two together
into a single typename.

Maybe we should have a patchset that does the uncontroversial
change (bits32->uint32_t &c, which I think should be purely
mechanical) while we argue about this bit?

-- PMM