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

Reply via email to