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 04:19:49 +0000

 > Date: Thu, 15 Jan 2026 03:51:28 +0000
 > From: 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.
 
 Alternatively: Why not use SA_RESTART, so you don't have to track down
 all the I/O logic that might be interrupted by a signal and arrange to
 run it in a loop?
 
 There's nothing here that behaves differently if it received a signal,
 like printing a progress bar if the I/O was interrupted by a signal --
 that's already done in the signal handler itself, isn't it?
 
 (Except you should probably use snprintf_ss, not snprintf, in
 progressbar.c, if you want to print the progress bar in the signal
 handler itself: snprintf is technically not async-signal-safe.  In
 practice on NetBSD, though, I think it matters only for the
 floating-point formatters, which may use malloc in gdtoa; the rest of
 it like %d and %s is probably safe.)