On 29 September 2017 at 12:14, Laurent Vivier <[email protected]> wrote: > Le 29/09/2017 à 18:50, [email protected] a écrit : >> From: Zhuowei Zhang <[email protected]> >> >> Linux returns success for the special case of calling write with a >> zero-length >> NULL buffer: compiling and running >> >> ``` >> >> int main() { >> ssize_t ret = write(STDOUT_FILENO, NULL, 0); >> fprintf(stderr, "write returned %ld\n", ret); >> return 0; >> } >> ``` >> gives "write returned 0" when run directly, but "write returned -1" in QEMU. >> >> This commit checks for this situation and returns success if found. >> >> Signed-off-by: Zhuowei Zhang <[email protected]> >> --- >> linux-user/syscall.c | 5 +++++ >> 1 file changed, 5 insertions(+) >> >> diff --git a/linux-user/syscall.c b/linux-user/syscall.c >> index 9b6364a..ecadf49 100644 >> --- a/linux-user/syscall.c >> +++ b/linux-user/syscall.c >> @@ -7783,6 +7783,11 @@ abi_long do_syscall(void *cpu_env, int num, abi_long >> arg1, >> } >> break; >> case TARGET_NR_write: >> + if (arg2 == 0 && arg3 == 0) { >> + /* special case: write(fd, NULL, 0) returns success. */ >> + ret = 0; >> + break; >> + } >> if (!(p = lock_user(VERIFY_READ, arg2, arg3, 1))) >> goto efault; >> if (fd_trans_target_to_host_data(arg1)) { >> > > I think we should keep the call to the kernel write() as the behavior > depends on the driver behind the syscall. Moreover, calling write() with > (NULL, 0) can triggers "something" at kernel level.
I tend to agree. On the other hand our handling of NR_read with a zero count just returns 0 without calling the syscall; perhaps we should change that for consistency? Do we also have the same issue with pread64/pwrite64 ? thanks -- PMM
