On 28 March 2017 at 11:19, John Paul Adrian Glaubitz
wrote:
> On 03/27/2017 07:34 PM, Peter Maydell wrote:
>> That all makes sense in isolation, but shouldn't something have
>> at least warned that "&h.size" isn't actually a uint32_t* in
>> the sense of being something you can validly pass to a
>>
On 03/27/2017 07:34 PM, Peter Maydell wrote:
> That all makes sense in isolation, but shouldn't something have
> at least warned that "&h.size" isn't actually a uint32_t* in
> the sense of being something you can validly pass to a
> function that takes a uint32_t* ?
It turns out that clang actuall
On 03/27/2017 07:34 PM, Peter Maydell wrote:
> That all makes sense in isolation, but shouldn't something have
> at least warned that "&h.size" isn't actually a uint32_t* in
> the sense of being something you can validly pass to a
> function that takes a uint32_t* ?
This seems to be related to thi
On 03/28/2017 03:34 AM, Peter Maydell wrote:
That all makes sense in isolation, but shouldn't something have
at least warned that "&h.size" isn't actually a uint32_t* in
the sense of being something you can validly pass to a
function that takes a uint32_t* ?
That's a long-known bug in the imple
At the moment the 9p QEMU tests fail on SPARC. This turns out to
be because the test case itself gets a SIGBUS. Looking at the
code I guess it makes sense, but I don't understand why the
code didn't at least generate a warning. Here's a cutdown testcase:
pm215@stadler:~$ cat packed.c
#include
#in
