Re: [Qemu-devel] [PATCH 0/6] Get rid of confusing softfloat-specific integer types

[Peter Maydell]

On 12 January 2016 at 12:55, Peter Maydell <address@hidden> wrote:
> This patchset removes the confusing softfloat-specific integer
> types int8, uint8, int32, uint32, int64 and uint64, replacing
> them with the standard _t types that they were typedef'd as.
> These frequently got accidentally used outside the softfloat
> code as a simple typo for the standard types (as you can see
> from the various files touched in the diffstat).
>
> Although there is technically a semantic difference (the
> softfloat types are "at least X bits" whereas the standard
> types are "exactly X bits", the distinction is unlikely to
> make much performance difference and "upgrading" the types to
> use int_fast*_t would require careful code analysis to check we
> weren't accidentally  relying on the type width. It also means
> we might potentially have subtle bugs on only some host platforms,
> which is worth avoiding I think.
>
> (In particular glibc defines int_fast32_t as a 64 bit type
> on 64 bit systems, which is unlikely to be the most sensible
> type to actually use for performance. I was reading a discussion
> about the _fast_ types from the musl irc channel recently:
> https://gist.github.com/andrewrk/ac66b24a0a202d87cea7
> which suggests that they're in practice not very useful.)
>
> This is admittedly a different decision to the one we made in
> the past for int16/uint16 (commits 94a49d86c536af3, 5aea4c589aa).
> I can do a followup patch which converts our int_fast16_t/uint_fast16_t
> usage to int16_t/uint16_t if people would like.
> (I think the difference is partly that the old int16/uint16 types
> really were bigger than 16 bits so we knew the code was not
> accidentally relying on exactly-16-bitness. Also I have a feeling
> that I was one of those suggesting the _fast_ types, but I have
> changed my mind and think I was wrong back then.)

Since this series has got positive review and nothing
negative I intend to commit it to master later this week.

thanks
-- PMM