On 12 January 2016 at 12:55, Peter Maydell <peter.mayd...@linaro.org> 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
