On Mon, Mar 07, 2011 at 11:14:11PM +0000, Peter Maydell wrote: > On 7 March 2011 09:56, Aurelien Jarno <aurel...@aurel32.net> wrote: > > On Mon, Mar 07, 2011 at 01:34:07AM +0100, Andreas Färber wrote: > >> AIX already didn't use our definition, so let's start ripping out this one: > >> As pointed out by Peter Maydell, int16 is currently int on most > >> supported platforms, so let's replace it with int_fast16_t, > >> allowing the system to use a wider type if appropriate. > > > > Do you have a rationale about the use of the fast version of the types? > > As you said it allows the compiler to use a wider type if appropriate, > > and this usually doesn't play very well when shifts are involved, which > > is the case of the softfloat code. Have you verified that each > > conversion is correct? On the other hand I really doubt it has a > > measurable impact on speed. > > > > I would really go for uint16_t for now. This might be changed to the fast > > version in a second step if we are sure everything is correct, but let's > > don't mix the two steps for now. > > As Andreas says, the code as it is at the moment makes the "wider > is OK" vs "exact width only" distinction, it just isn't using the > standard typenames to do it. So changing "int16" to "int16_t" would > be the change of semantics (both in theory and in practice, since at > the moment "int16" is int). >
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. 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. -- Aurelien Jarno GPG: 1024D/F1BCDB73 aurel...@aurel32.net http://www.aurel32.net
