Just thought I'd share a little tippet that I figured out after a few hours of troubleshooting my codebase on a new Mac that was crashing after compile while still compiling and running flawlessly on the older Mac I'd been working on:
The newest flavors of *nix are addressing the issue of 2038 by redefining time_t as a long int. This can cause issues when treating a time_t value like an int in your legacy code base once you compile and run the code on a 64-bit system (I know for sure on Mac OS 10.6+, and likely the 64-bit flavor of your fave Linux). On mine, I finally had to track down and replace all the int's that referenced my mud time (the function that returns a date/time string, as a good example), and change them to long.
The mud stopped crashing at every function that called current_time, and as a side benefit, I don't have to worry about scurrying around at the end of 2037 trying to keep my mud from shutting down! >.>
Technically, you shouldn't be using either int or long, but time_t, since it will be the correct size on the system it's being compiled on. Meaning in another 10 years when 128-bit ints are normal, you won't have to go fix it again.
The newest flavors of *nix are addressing the issue of 2038 by redefining time_t as a long int. This can cause issues when treating a time_t value like an int in your legacy code base once you compile and run the code on a 64-bit system (I know for sure on Mac OS 10.6+, and likely the 64-bit flavor of your fave Linux). On mine, I finally had to track down and replace all the int's that referenced my mud time (the function that returns a date/time string, as a good example), and change them to long.
The mud stopped crashing at every function that called current_time, and as a side benefit, I don't have to worry about scurrying around at the end of 2037 trying to keep my mud from shutting down! >.>