On 2 September 2011 19:18, Andreas Färber wrote:
> What about my preparatory patches? Can you ack them?
Sorry, yeah, I'd missed those; that cleanup is worth doing
whatever we decide to do here. Now reviewed.
-- PMM
Am 02.09.2011 um 18:38 schrieb Peter Maydell:
2011/8/28 Peter Maydell :
On 28 August 2011 14:02, Alexander Graf wrote:
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 dep
2011/8/28 Peter Maydell :
> On 28 August 2011 14:02, Alexander Graf wrote:
> 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
On 28.08.2011, at 09:08, Peter Maydell wrote:
> On 28 August 2011 14:47, Alexander Graf wrote:
>> Well, if we want host machine dependent types we should use host
>> dependent types.
>
> ...we couldn't decide what we wanted :-)
>
>> Apparently uint16 is expected to be uint32_t in the code IIU
On 28 August 2011 14:47, Alexander Graf wrote:
> Well, if we want host machine dependent types we should use host
> dependent types.
...we couldn't decide what we wanted :-)
>Apparently uint16 is expected to be uint32_t in the code IIUC.
If the softfloat code relies on uint16 being exactly 32 b
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 rejec
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
On 28 August 2011 14:02, Alexander Graf 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
>> t
On 28.08.2011, at 07:09, Andreas Färber wrote:
> Hello,
>
> The unresolved softfloat uint* conversion business bites us again: This time,
> the previously working Cocoa frontend stopped compiling:
>
> In file included from /Users/andreas/QEMU/qemu/bswap.h:14,
> from /Users/andr
Hello,
The unresolved softfloat uint* conversion business bites us again:
This time, the previously working Cocoa frontend stopped compiling:
In file included from /Users/andreas/QEMU/qemu/bswap.h:14,
from /Users/andreas/QEMU/qemu/qemu-common.h:103,
from /Use
10 matches
Mail list logo
