On 16.01.2012, at 20:17, Peter Maydell wrote: > 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...
Yeah, but it's safe. And I would assume that 32bit integers are better optimized for than smaller ones in today's CPUs. Alex