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


Reply via email to