On 28 August 2011 14:02, Alexander Graf <ag...@suse.de> 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
