[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PATCH 2/4] Avoid multiple definitions of copy_file_range
From: |
Samuel Thibault |
Subject: |
Re: [PATCH 2/4] Avoid multiple definitions of copy_file_range |
Date: |
Wed, 17 Jan 2024 16:03:23 +0100 |
User-agent: |
NeoMutt/20170609 (1.8.3) |
Hello,
Manolo de Medici, le mer. 17 janv. 2024 15:47:09 +0100, a ecrit:
> ../../../block/file-posix.c:2003:14: error: conflicting types for
> 'copy_file_range'; have 'off_t(int, off_t *, int, off_t *, size_t,
> unsigned int)' {aka 'long long int(int, long long int *, int, long
> long int *, unsigned int, unsigned int)'}
> 2003 | static off_t copy_file_range(int in_fd, off_t *in_off, int out_fd,
> | ^~~~~~~~~~~~~~~
> In file included from /root/qemu/include/qemu/osdep.h:122,
> from ../../../block/file-posix.c:25:
> /usr/include/unistd.h:1142:9: note: previous declaration of
> 'copy_file_range' with type 'ssize_t(int, __off64_t *, int,
> __off64_t *, size_t, unsigned int)' {aka 'int(int, long long int *,
> int, long long int *, unsigned int, unsigned int)'}
> 1142 | ssize_t copy_file_range (int __infd, __off64_t *__pinoff,
> | ^~~~~~~~~~~~~~~
>
> the current patch fixes this compilation error.
Yes, but by ignoring the difference :)
The prototype of copy_file_range in glibc really does say that it
returns an ssize_t, not an off_t, so that should be fixed so.
Samuel
- [PATCH 2/4] Avoid multiple definitions of copy_file_range, Manolo de Medici, 2024/01/17
- Re: [PATCH 2/4] Avoid multiple definitions of copy_file_range, Philippe Mathieu-Daudé, 2024/01/17
- Re: [PATCH 2/4] Avoid multiple definitions of copy_file_range, Manolo de Medici, 2024/01/17
- Re: [PATCH 2/4] Avoid multiple definitions of copy_file_range, Samuel Thibault, 2024/01/17
- Re: [PATCH 2/4] Avoid multiple definitions of copy_file_range, Manolo de Medici, 2024/01/17
- Re: [PATCH 2/4] Avoid multiple definitions of copy_file_range,
Samuel Thibault <=
- Re: [PATCH 2/4] Avoid multiple definitions of copy_file_range, Manolo de Medici, 2024/01/17
- Re: [PATCH 2/4] Avoid multiple definitions of copy_file_range, Samuel Thibault, 2024/01/17
- Re: [PATCH 2/4] Avoid multiple definitions of copy_file_range, Manolo de Medici, 2024/01/17