On 16 January 2012 19:12, Alexander Graf <ag...@suse.de> wrote: > > On 16.01.2012, at 20:02, Peter Maydell wrote: >> The changes from int32/uint32 to int_fast32_t/uint_fast32_t are >> the potentially dangerous ones in this set, since they change a >> type that was easily mistaken for "exactly 32 bits" and happened >> to be 32 bits to one that is now 64 bits (on 64 bit hosts). >> The other type changes are either "not a width change in practice" >> (int64) or "change from something that was already wider than the >> number in it" (int16) or "wasn't being used for things where we >> really cared about the type width" (int8, flag). >> >> Specifically, it's this change that revealed the latent bugs I >> sent a three-patch set for, and so it doesn't seem too unlikely >> that other platforms may have some similar bugs in their >> int-to-float/float-to-int code that will now be revealed on >> 64 bit hosts. >> >> I don't think that means we shouldn't apply this patch set but >> I would recommend some testing of other architectures :-) > > So what if we leave uint32_t be uint32_t and make the other ones _fast_?
We'd need to get Andreas to do another benchmark run to check that this didn't lose the perf gain. Also it's kind of aesthetically not very pleasing... -- PMM
