On 31 December 2013 14:35, Richard Henderson <rth@xxxxxxxxxxx> wrote: > On 12/31/2013 06:27 AM, Peter Maydell wrote: >> 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? OK, let's make this one return int16_t. I may throw in an extra patch making the other int-to-float routines take the precise types too. > One of these days we should just clean up all the crap formatting, bogus types, > and stupid STATUS_* macros... Yes, the STATUS_ stuff is definitely on my list to zap, once we get all this stuff reviewed and committed (since it would otherwise cause conflicts all over the place). I think the standing question about the types is whether we should be converting int32 to int32_t or int_fast32_t (and indeed whether it makes much performance difference). That's why we have the current setup where some of the intfoo got changed to int_fastfoo_t and some didn't. My other hope for this year is that we can clear up the relicensing stuff so I don't have to keep prodding people about specifying the 2a-or-2b stuff on new patches... thanks -- PMM _______________________________________________ kvmarm mailing list kvmarm@xxxxxxxxxxxxxxxxxxxxx https://lists.cs.columbia.edu/cucslists/listinfo/kvmarm
