Am 17.12.2010 um 17:48 schrieb Peter Maydell:
On 17 December 2010 16:19, Andreas Färber <andreas.faer...@web.de>
wrote:
Can this patch be applied? (There are more ARM/softfloat patches
in my queue which will break it again otherwise...)
If we're engaging into refactoring the softfloat library, I still
have a
large'ish patch lying around to fix signature mismatches between
header and
sources wrt to integer arguments and migrating to POSIX integer types
(BeOS/Haiku system headers define int32 etc. differently). Browsing
through
your patch it shouldn't conflict, but I guess it'll be best to have
it go
through your queue to avoid troubles.
I wasn't planning to put this patch into my "ARM fixes" queue to be
pulled directly, because it's a bit wider in scope than fixing things
for ARM targets. (Hence the "can this be applied?" request :-))
On the types issue, at the moment softfloat uses "int32" etc for
"a handy type holding at least 32 bits", and "bits32" for "exactly
32 bits". So I guess changing the 'bits' types to the POSIX int32_t
and friends would be straightforward enough, but what does your
patch do with the int32 types?
My patch does not touch the bits* types. I didn't notice any problem
there.
I replaced int32 by int32_t, int64 by int64_t etc. No sane code puts
more than 32 bits into an "int32" variable, and my guests on OSX/ppc64
host still appeared to work. I don't have arm guests though so please
check on your side.
There's int_least*_t in case we really need it:
http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/stdint.h.html
Andreas
