Re: [Qemu-devel] [PATCH v2] syscall: fix special case of write(fd, NULL, 0)

[Carlo Arenas]

after looking at this further, I am now convinced this patch (while
correct) is only addressing the symptom and not the root cause, and
therefore should be improved.

the smoking gun is that it is not needed, when the guest bitness is smaller
than the host (ex: qemu-i386 in an amd64 host) and the real problem is that
the current code assumes NULL is always an access failure, while it is the
right response when NULL is passed as the buffer parameter.

will update my proposed fix for pwrite64 with code that fixes both places
but that still matches the observed behaviour and throws and error when it
really needs to (as per the documentation) :

address@hidden:/usr/src/qemu# aarch64-linux-gnu-gcc -static -o t.arm64
t.c

*t.c:* In function '*main*':

*t.c:11:28:* *warning: *passing argument 2 of '*write*' makes pointer from
integer without a cast [*-Wint-conversion*]

    ssize_t ret = write(fd, *-*1, 0);

                            *^*

In file included from *t.c:2:0*:

*/usr/aarch64-linux-gnu/include/unistd.h:369:16:* *note: *expected '*const
void **' but argument is of type '*int*'

 extern ssize_t *write* (int __fd, const void *__buf, size_t __n) __wur;

                *^~~~~*

address@hidden:/usr/src/qemu# ./aarch64-linux-user/qemu-aarch64 ./t.arm64


write returned -1 with errno 14 (Bad address)

had also proposed a test case[1] but I suspect that qemu might had been
accidentally compliant since it is clear (at least from the documentation)
that an EFAULT might be a valid response as well, and it might be what is
returned at least on some linux systems using uclibc

Carlo

[1] https://github.com/linux-test-project/ltp/pull/217