Todd C. Miller wrote:
> On Fri, 19 Aug 2016 19:14:54 -0400, "Ted Unangst" wrote:
>
> > hmm. so I was trying to avoid the need for two different functions. I think
> > there's a mental overhead to "do this, then maybe that". this loop reads
> > very strangely to me. it's hard to mentally trace the
include
-#include
void abort_remote(FILE *);
void abortpt(int);
@@ -76,7 +75,7 @@ void cmdabort(int);
void cmdscanner(int);
intcommand(const char *, ...);
int confirm(const char *, const char *);
-intconnect_sync(int, const struct sockaddr *, socklen_t);
+intconnect_w
Todd C. Miller wrote:
> Here's a rewrite of my connect_sync() changes to use connect_wait()
> instead. Unlike the version in the connect(2) manual, this one
> returns EINTR when interrupted by a signal which is probably better.
> Index: us
Here's a rewrite of my connect_sync() changes to use connect_wait()
instead. Unlike the version in the connect(2) manual, this one
returns EINTR when interrupted by a signal which is probably better.
- todd
Index: usr.bin/ftp/ext
Another option is to use the connect_wait() function I added to
EXAMPLES in connect(2). You would only call it if connect(2) returns
-1 with errno == EINTR.
- todd
connect_sync looks like it could be a useful piece of code in other places.
however, putting the loop in the function means that ^C may not work... ftp
has disgusting signal handlers and longjmps, but i don't think that's how we
want other programs to be written.
i've rewritt
