Raw Text TCP Client

A few notes:

• As Jamal noted in the comments, your definitions of STDIN and STDOUT are somewhat useless. You can see here that using the given STDIN_FILENO and STDOUT_FILENO are already given those values. To counter your claim in the comments that they help readability, I would argue that they actually clutter up your code and should be removed.

• Declaring run as a global variable isn't the best way to use signal handlers IMO. I would consider just testing the return value from signal for SIGINT in your while loop and quitting if that becomes true. I haven't tested this, but you shouldn't even need a sighandler_t for that.

• The typical way that main() is written is as such:

  int main(int argc, char **argv)
  

  Note the argc, not the args. This actually stands for something ("argument count"), just like argv has a meaning as well ("argument vector").

• All declarations should be on their own line. From Code Complete, 2d Edition, p. 759:

  With statements on their own lines, the code reads from top to bottom, instead of top to bottom and left to right. When you’re looking for a specific line of code, your eye should be able to follow the left margin of the code. It shouldn’t have to dip into each and every line just because a single line might contain two statements.

• Always initialize your values. Right now, you've only initialized one value to 0. Initialize them all. This is to safeguard against some possible weird bugs.

• Don't assert anything that has to do with user input. Assertions are to be used to indicate the programmer's errors, not errors of the users. Instead, test if the input is what you'd like, and if it's not then print a message telling the user what they did wrong and return an error code.

• Use braces with your if-else conditionals please. See the Apple goto fail as for a good reason why.

This may not be useful for accounting for invalid command line arguments:

assert(args == 3);

It's more common to inform the user of the correct arguments upon failure. This message should be printed to stderr and the program should terminate with some valid error value.

Here's an example of this:

if (argc != 3)
{
    fprintf(stderr, "usage: %s arg1 arg2", argv[0]);
    exit(EX_USAGE);
}

(EX_USAGE is part of <sysexits.h>.)

You are assuming that the socket and the console are immediately writeable, so your program can get blocked if that is ever not the case. I'd use the "write" set of fds in the select call to test the waters, my answer over here has a bit of example code.

This can also be used to connect asynchronously -- you'd wait for the socket fd to become writeable, then you know that the connection is established. If the connection fails, the fd becomes readable, and you get an error for actually trying to read.

A few other points:

1. In function declarations, parameters need not have names because the compiler only needs to know what types such function may be called with.

   void sigint_handle(int dummy); 
   int connect_to(char *host, int port);
   int transfer(int fd_in, char *buf, int buf_len, int fd_out);
   

2. In volatile int run = 1, int is not totally a good choice. The type guaranteed to be able to be accessed atomically -across asynchronous interrupts, for instance- is sig_atomic_t. See this answer, in particular:

   (§7.14 , paragraph 2) The type defined is sig_atomic_t, which is the (possibly volatile-qualified) integer type of an object that can be accessed as an atomic entity, even in the presence of asynchronous interrupts. (§7.14 , paragraph 2)

   (§7.14p5) If [a] signal occurs other than as the result of calling the abort or raise function, the behavior is undefined if the signal handler refers to any object with static storage duration other than by assigning a value to an object declared as volatile sig_atomic_t.

3. struct sockaddr_in addr; memset(&addr, 0, sizeof(addr)) is not really needed because you want to set each field of the struct to zero, not each byte which may also include padding ones. Simply do struct sockaddr_in addr = {0}.

4. This rearrangement looks better and more solid

   addr.sin_family = AF_INET;
   addr.sin_port   = htons(port);
   assert(inet_pton(addr.sin_family, host, &addr.sin_addr) > 0);
   

5. Watch out for assert: as it has been said, it should not be used for error handling but for debugging bugs. assert can, indeed, do nothing (and so hide bugs) if NDEBUG is defined!