OK, I'm not going to do you homework for you. However, you should seriously consider running this program through a pretty printer. The formatting is so bad that it's a wonder you can read it yourself. And, so many variables names starting with "m" and "h"? Try giving the variables meaningful names so you can follow the logic better.

Once that's aLL taken care of, you can actually describe what's not working. You didn't tell us anything about the failure mode you're seeing.

Good luck...

Well, I'm not going to do your homework for you. However, you should look closely at your numeric sorting function. It sorts the numbers, but it's missing something important.

@Jim, wow this code is a real piece of work. My head hurt just looking at all those labels and gotos. Now, I do use gotos in my C code in the Linux kernel, but that's pretty much the standard way to write drivers in Linux. Still, none of that even compares to the gem you've just shared.

Thanks for reminding me just how bad code can get.

At one time, I used to write a lot of FORTRAN code. In FORTRAN, many of these gems were ingrained in the way you were taught (i,j,k as integer variables, etc.). As I read through this, I had deja vu all over again with some of the code I've come across. However, the height of obfuscation is not making the code look obfuscated. That is a black art unto itself. ;-)

Here's a good explaination of ICMP redirects and when they're sent:

Actually, you should consider making the default lease time much shorter. More like 30 minutes. This does increase the number of lease renewals, but guarrantees that anyone who's not actively on the network gets their IP dropped for reuse by someone else.

If you're running any of the Debian-based distros, an "apt-get install build-essential" will install everything you need to be able to develop C/C++ code on Linux. Then make sure that you use the CDT (C/C++ developer toolkit) version of Luna rather than the Java version to be able to find the compiler for native compliation in Eclipse.

If you're sending this with TCP sockets, the data will be converted to a stream of bytes and stuffed into the packet to be sent. There are no delimiters placed into the stream by the protocol. And, there's no guarrantee that you will get full MTU transfers (the Nagle algorithm might get in your way). So, if you do a write(fd, buf, 2048) (assuming there were 2048 bytes in the buffer at address buf), there's really know way to know how the packets will be delivered. However, you do know that they will be delivered in the order they were sent and they will get there eventually.

So, on the receiver side, you simply continue to read from the socket until you have the same number of bytes that you sent on the sender's side. This is the technique if you have fixed record lengths. If you have variable record lengths, then you'll need a fixed size message header that describes the size of the message, followed by the message itself. Read and decode the header and then read that number of bytes to get the enitre message.

In this case, FORTRAN formats arrays in column-major order. That is, columns are adjacent in memory instead of the rows (C is row-major order). So, the developer is taking advantage of that knowledge in the way he/she is passing parameters. As you can see, this is really bad practice because it confuses the hell out of folks looking at the code.

Get ready for the new machines that are built to run WIndows 8. They will have a TPM installed that only has MS WIndows as a boot option. Booting from USB/CDROM will now be impossible if the BIOS vendor doesn't give you a way to disable the TPM or reload a new boot signature. So, If you're thinking of getting a new machine this year, you better do it before WIndows 8 becomes official. Once that comes out, you might have to switch to an ARM-based machine to escape the Microsoft monopoly.