|
0ac98783
|
2022-01-14T17:27:51
|
|
copy-file-range: work around Linux kernel bug
This workaround is adapted from Coreutils.
* lib/copy-file-range.c [__linux__ && HAVE_COPY_FILE_RANGE]:
Include <sys/utsname.h>.
(copy_file_range): Use a stub to replace the copy_file_range of
Linux kernel versions 4.5 through 5.2.
* lib/unistd.in.h (copy_file_range):
* m4/unistd_h.m4 (gl_UNISTD_H_DEFAULTS):
* modules/copy-file-range (configure.ac):
* modules/unistd (unistd.h):
Support replacement of copy_file_range.
* m4/copy-file-range.m4 (gl_FUNC_COPY_FILE_RANGE):
Define HAVE_COPY_FILE_RANGE if the system has copy_file_range,
and on Linux check whether the system’s is known to work.
|
|
|
eec12c00
|
2022-01-01T09:43:19
|
|
maint: run 'make update-copyright'
|
|
|
4b948321
|
2021-01-01T07:28:52
|
|
maint: run 'make update-copyright'
|
|
|
2cdc1baf
|
2020-01-01T00:00:18
|
|
maint: Run 'make update-copyright'
|
|
|
b0d998d2
|
2019-06-06T15:44:33
|
|
copy-file-range: simplify into a stub
Based on a comment by Florian Weimer in:
https://lists.gnu.org/r/bug-gnulib/2019-06/msg00007.html
It turns out that Emacs (which will use this module) won’t need an
emulation and I suspect other programs won’t either, because these
programs will need to fall back on read+write anyway. Perhaps I
am wrong and other programs will be able to use an emulation; if
so, this patch can be reverted.
* lib/copy-file-range.c (COPY_FILE_RANGE): Replace with a stub.
Just call it copy_file_range.
* m4/copy-file-range.m4 (gl_FUNC_COPY_FILE_RANGE):
Check via AC_LINK_IFELSE.
* modules/copy-file-range (Depends-on): Remove modules no longer used.
|
|
|
508eb991
|
2019-06-04T19:54:09
|
|
copy-file-range: new module
* MODULES.html.sh: Add copy-file-range.
* lib/copy-file-range.c, m4/copy-file-range.m4:
* modules/copy-file-range: New files.
* lib/unistd.in.h (copy_file_range): Declare.
* m4/unistd_h.m4 (gl_UNISTD_H_DEFAULTS):
Set up GNULIB_COPY_FILE_RANGE and HAVE_COPY_FILE_RANGE.
* modules/unistd (unistd.h): Substitute them.
|