qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Alexander Graf
Subject: Re: [Qemu-devel] softfloat breaks cocoa.m
Date: Sun, 28 Aug 2011 08:47:16 -0500

On 28.08.2011, at 08:34, Andreas Färber wrote:

> Am 28.08.2011 um 15:02 schrieb Alexander Graf:
> 
>> 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?
> 
> The core issue is this: uint16 in fpu/ does not mean uint16_t but "at least 
> 16 bits wide" (int). Apart from the BeOS/Haiku i386 ABI being strange in 
> using long for uint32, most uses of uint16 elsewhere mean "exactly 16 bits 
> wide", leading to type conflicts.
> 
> POSIX has two types for such least-width semantics: uint_least16_t and 
> uint_fast16_t. We ran into the issue that a patch compiled on Darwin/ppc64 
> but broke on Linux/x86_64 or i386, so Aurelien considered it too risky to use 
> types whose actual width depends on the host system within my series.

Well, if we want host machine dependent types we should use host dependent 
types. If not, why can't we just typedef them to uint32_t or uint64_t and call 
it a day? Apparently uint16 is expected to be uint32_t in the code IIUC.


Alex




reply via email to

[Prev in Thread] Current Thread [Next in Thread]