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

[Luke Mewburn <luke%mewburn.net@localhost>]

On 26-01-15 04:19, Taylor R Campbell wrote:
  | > 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?

Even on NetBSD, the previous use of restartable signals (SA_RESTART)
caused issues with the implementation of -q QUITTIME.
That's why I changed ftp 20210106 to always use interruptable
signals for PR 55857 - as confirmed by the submitter.


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