Re: [Qemu-devel] softfloat breaks cocoa.m

[Peter Maydell]

On 28 August 2011 14:02, Alexander Graf <address@hidden> wrote:
> On 28.08.2011, at 07:09, Andreas Färber wrote:
>> Any thoughts on how to proceed? My previous approach for Haiku,
>> to replace non-standard uint16 with POSIX uint_fast16_t etc.,
>> was rejected to avoid system-dependent widths. I'd really like
>> to get rid of the annoyingly conflicting naming though (int vs.
>> long for 32, int vs. short for 16, ...).
>
> I'm not sure what you mean by system-dependent widths? This is
> only a naming collision issue, right? Can't we just name the types
> something more qemu specific?

If I recall the previous discussions correctly:

At the moment softfloat has its own typedefs (int16 etc) which
it uses to mean "an int which must be at least 16 bits wide but
may be larger"; the POSIX names for these (as Andreas says) are
int_fast16_t &c. (We've already converted softfloat's custom
typedefs for "int which must be exactly 16 bits" &c to use the
posix int16_t &c, so those are not a problem any more.)

There are two ways we can fix the naming clash here:

(1) change int16 -> int_fast16_t. This was argued against because
it means that the type might have a different width depending on
the host system, which means that where softfloat buggily makes
assumptions about the typewidth this would surface only on the
minority of systems where (eg) int_fast16_t wasn't 32 bits.
(In theory this is just preserving current behaviour but in fact
the set of typedefs in softfloat.h doesn't take advantage of the
"may be bigger" leeway; for example we 'typedef int8_t int8' even
though the comment above specifically suggests that int8 should
be typedef'd as an int.)

(2) change int16 -> int16_t. This was argued against because it
would be dropping the information in the current softfloat code
about where we require a 16 bit type for correctness and where
we are happy for the type to be larger if it's more efficient.

Unfortunately we didn't manage to come to a consensus on one
of these two approaches, which is why we haven't renamed the
offending types yet...

[Personally I prefer (2).]

-- PMM