The easier it is to read the code, the easier it is to spot bugs and flaws in it. Use common formatting. It's hard to read when your function blocks are not indented, it looks like everything is in global scope. The readability is also increase with sensible variable names. Don't have two variables named s and s_. How am I going to keep track of which is what? You could call them server and client. handle has a parameter int s, which to the reader could be anything without checking for how the function is called. Call it socket or client.

Don't use bzero, it was deprecated in 2001 and removed from POSIX in 2008. Use the ANSI standard memset instead. It's more versatile and portable.

Your code is vulnerable to a timing attack. Since you are comparing the input string byte for byte and breaking out of the loop whenever a non matching byte is found, the response time can be measured to estimate how many leading bytes match. You should be executing the whole loop, even though you know they don't match.

The easier it is to read the code, the easier it is to spot bugs and flaws in it. Use common formatting. It's hard to read when your function blocks are not indented, it looks like everything is in global scope. The readability is also increase with sensible variable names. Don't have two variables named s and s_. How am I going to keep track of which is what? You could call them server and client. handle has a parameter int s, which to the reader could be anything without checking for how the function is called. Call it socket or client.

Don't use bzero, it was deprecated in 2001 and removed from POSIX in 2008. Use the ANSI standard memset instead. It's more versatile and portable.

Your code is vulnerable to a timing attack. Since you are comparing the input string byte for byte and breaking out of the loop whenever a non matching byte is found, the response time can be measured to estimate how many leading bytes match. You should be executing the whole loop, even though you know they don't match.