On Sat, 18 Dec 2010, Andreas F?rber wrote:
> Am 18.12.2010 um 11:39 schrieb Peter Maydell:
>
> > On 18 December 2010 02:30, Nathan Froyd <froy...@codesourcery.com> wrote:
> > > I wouldn't be too worried:
> > >
> > > typedef uint8_t flag;
> > > typedef uint8_t uint8;
> > > typedef int8_t int8;
> > > typedef int uint16;
> > > typedef int int16;
> > > typedef unsigned int uint32;
> > > typedef signed int int32;
> > > typedef uint64_t uint64;
> > > typedef int64_t int64;
> > >
> > > So adding _t suffixes in appropriate places should be a no-op, except
> > > for uint16/int16--and those types are never used.
> >
> > Eh? If you comment out the int16 typedef you'll find softfloat.c
> > doesn't compile because of all the places it's used... (uint16
> > isn't used, though.) A lot of the int16 uses are things like shift counts
> > which should probably go to plain old 'int' rather than 'int16_t'.
> >
> > Also, are we sure we want to throw away the current information
> > in the code about the distinction between "I need at least X bits"
> > and "I need exactly X bits" ?
>
> IMO a lot of code in QEMU is cryptic because someone thinks that someone else
> must've thought something particular when doing it that way and is thus
> reluctant to touch it...
>
> For a fact, [u]int8 und [u]int64 remain unchanged width-wise.
> For [u]int16, only malc may know what that maps to on AIX, for which they are
> #ifndef'ed out. I doubt it's an int.
AIX leaks all sorts of stuff from system headers, i don't remember what
int16 is defined as.
> Unless there's an ILP64 platform we support, [u]int32 would stay the same
> width, too.
> That's why I was saying, putting, e.g., a 33rd bit into int32 has undefined
> semantics, just as for the POSIX int_least32_t type. I don't see a win in
> declaring that information.
>
> My patch tries to do three things in one:
> 1.) Fix mismatches between headers and sources, i.e. float32
> int32_to_float32(int); vs. float32 int32_to_float32(int32) {...} etc.
> 2.) Drop the unnecessary custom integer types in favor of standard ones.
> 3.) Fix instances of lazyness where _t was forgotten and the mistake was
> hidden by the softfloat typedefs.
>
> Renaming int32 to qint32 would defeat the second purpose. I got around the
> Haiku issue for now, so that's not a pressing need.
>
> Had the softfloat code not been a real refactoring-unfriendly mess of int,
> int* and int*_t, I would've offered to do this in multiple steps per type. I
> could try splitting out part 1 above. Part 3 can easily be split off by
> cut-and-paste and could be applied independently.
>
> Promoting int16[_t] to int for things like shift counts is beyond the scope of
> my patch.
>
> Andreas
--
mailto:av1...@comtv.ru
