Paul Eggert <egg...@cs.ucla.edu> writes: > In the old days, safe_read acted more like what full_read does now. > When that went away, some code that invoked safe_read should > have gone back to plain 'read' but I guess we never got around to it. > Simplify this code by going back to plain 'read'. > Use safe_read only in csplit.c, which has a signal handler > and where 'read' can therefore fail with EINTR. > Although safe_read also checks for oversize buffers, > that is better done via io_blksize. > * src/cat.c (simple_cat, cat): > * src/head.c (copy_fd, elide_tail_lines_pipe) > * src/tac.c (tac_seekable, copy_to_temp): > (elide_tail_lines_seekable, head_lines): > * src/tail.c (dump_remainder, file_lines, pipe_lines) > (pipe_bytes, start_bytes, start_lines, tail_forever_inotify): > * src/tr.c (plain_read): > Use plain 'read', not safe_read, since there is no > need to worry about signals or oversize requests. > Also, there is no longer a need to include safe-read.h. > * src/ioblksize.h: Include sys-limits.h, for SYS_BUFSIZE_MAX. > (io_blksize): Max out at SYS_BUFSIZE_MAX. > ---
Thanks, I was a bit confused why 'safe_read' was used in many places where a signal handler could not interrupt 'read'. I assumed that I must have been missing something. But I guess that something was the just the behavior change you mention. I found the change from 30 years ago[1]. :) Collin [1] https://git.savannah.gnu.org/gitweb/?p=gnulib.git;a=commit;h=1934bbbae2095a684c35adeee169867abe734277