On 7 March 2011 23:37, Aurelien Jarno <aurel...@aurel32.net> wrote: > I understand your point, but OTOH int_fast16_t means at least int16_t so > in practice it doesn't bring anything more than changing to int16_t, > except more pain as the size actually depends on the host.
But at the moment we implement int16 as int, so (a) we'd be telling the compiler it needed to use a type that was (fractionally) less efficient and (b) we already know that the code can cope with the type being wider than 16 bits, because that's how we're compiling the code today. The thing we should be worrying about is that maybe there's code that accidentally requires more than 16 bits in an int16 which would break if you defined it as an int16_t... > If we want to change the int here, we should either use int32_t here > (which matches the size of int), or just look case by case and use the > correct type. Correct choice between 'bits16' and 'uint16' is actually one of the areas where I pretty much trust the original softfloat code: I think it's definitely a retrograde step to throw that away, and personally I would NAK any patch which merges the two together into a single typename. Maybe we should have a patchset that does the uncontroversial change (bits32->uint32_t &c, which I think should be purely mechanical) while we argue about this bit? -- PMM