On 12/31/2013 06:27 AM, Peter Maydell wrote: > I was going for consistency with the convert-to-int16, which return > int_fast16_t. Perhaps, but in that case we've properly bounded the result; it's guaranteed to be in range of int16_t. > The existing int32_to_float* functions take int32, not int32_t, > so this is the same semantics. You could argue that it would > be better for all of them to take the exact type rather than > the at-least-this-big type (it would let me drop a cast in the > ARM code that calls these), I suppose. Yes, that's what I'm arguing. Of course, I'd forgotten that we already have that problem, since my eyes refuse to see the lack of "_t" there. But is that existing bug any reason to extend the problem? One of these days we should just clean up all the crap formatting, bogus types, and stupid STATUS_* macros... r~ _______________________________________________ kvmarm mailing list kvmarm@xxxxxxxxxxxxxxxxxxxxx https://lists.cs.columbia.edu/cucslists/listinfo/kvmarm
