Re: bin/59587: ftp client ascii transfers with progress report fail

[Taylor R Campbell <riastradh%NetBSD.org@localhost>]

> Module Name:    src
> Committed By:   lukem
> Date:           Sat Dec  6 06:20:23 UTC 2025
> 
> Modified Files:
>         src/usr.bin/ftp: extern.h ftp.c util.c version.h
> 
> Log Message:
> ftp: fix ascii transfers with progress bar
> 
> Handle stdio interruption by signals and improve error handling
> in getc() and putc() on the control and data channels.
> Provide ftp_getc() and ftp_putc() wrappers that:
> - Retry the operation on EINTR or EAGAIN instead of failing.
> [...]
> +	while ((res = getc(fin)) == EOF) {
> +		if (feof(fin))
> +			break;		/* return EOF */
> +		if (ferror(fin)) {
> +			if ((errno == EINTR) || (errno == EAGAIN)) {
> +					/* retry on EINTR or EAGAIN */
> +				clearerr(fin);
> +				continue;

Why do you loop on EAGAIN?

Is the underlying file descriptor non-blocking?

=> If it is non-blocking, then you presumably need to wait in
   select/poll for input to arrive -- otherwise this is a busy-wait.

=> If it isn't non-blocking, then you should never get EAGAIN here --
   EAGAIN is generally only for non-blocking I/O calls to report that
   they can't perform the requested operation until you wait in
   select/poll for something to become ready (some input data to
   become ready or some output data to be processed from the buffer).

Or is there a bug somewhere that causes some syscall or library
routine involved to return EAGAIN on a signal, when it should really
either restart or return EINTR?  (I have never seen such a bug.)