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

["Taylor R Campbell via gnats" <gnats-admin%NetBSD.org@localhost>]

The following reply was made to PR bin/59587; it has been noted by GNATS.

From: Taylor R Campbell <riastradh%NetBSD.org@localhost>
To: Luke Mewburn <lukem%NetBSD.org@localhost>
Cc: source-changes-d%NetBSD.org@localhost,
	gnats-bugs%NetBSD.org@localhost, netbsd-bugs%NetBSD.org@localhost,
	Johnny Billquist <bqt%softjar.se@localhost>
Subject: Re: bin/59587: ftp client ascii transfers with progress report fail
Date: Thu, 15 Jan 2026 03:51:28 +0000

 > 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.)