更改一个列表改变了另一个列表(Changing one list changed the other list)

 （我不知道我是否应该得到答案，因为如果没有Harry Johnston和indiv的评论，我不会意识到问题是什么，但我会尝试将评论扩展为完整答案。） 
 
 正如indiv解释的那样， makedefs.exe崩溃的原因是因为ctime返回NULL。 通常你不会指望ctime这样做，所以我们需要查看文档，找出它会在什么情况下返回错误。 由于MinGW用于编译，我们需要查看Microsoft的Visual C ++文档。 这是因为MinGW没有它自己的C运行时，它只使用微软的。 
 
 查看ctime的Visual Studio C运行时库参考条目，我们发现： 
 
 
 
 回报价值 
 
 
 指向字符串结果的指针。 如果出现以下情况，将返 
 
 
 
  
 时间表示1970年1月1日午夜之前的一个日期。 
 
  
 如果使用_ctime32或_wctime32 ，则时间表示2038年1月19日03:14:07之后的日期。 
 
  
 如果您使用_ctime64或_wctime64 ，则time表示在UTC，12月31日23:59:59之后的日期。 
 
 
 
 
 现在，假设原始海报没有将系统时钟设置为远期或过去很长时间，这是非常安全的。 那么为什么ctime会使用错误的时间呢？ Harry Johnston指出代码使用long而不是time_t来存储时间值。这并不太令人惊讶。 Nethack实际上是旧代码，最初Unix以long值存储它的时间，使用time_t作为时间值后来出现。 Nethack将不得不处理那些没有时间的旧系统，以便在其活跃的开发周期中占据重要位置。 
 
 这就解释了为什么Nethack源使用了错误的类型，但它并没有完全解释为什么它将错误的值传递给ctime 。 事实上我们没有看到ctime本身的返回值的描述，只是_ctime32和_ctime64给了我们一个线索。 如果time_t是64位类型，那么使用long代替将是一个问题。 在Windows上， long只有32位，所以它意味着ctime传递的是一个部分时间值的数字，一部分是随机位。 阅读文档证实了这种情况，并为我们提供了一个可能的解决方案： 
 
 
 
 ctime是一个内联函数，其值为_ctime64 ， time_t等于__time64_t 。 如果需要强制编译器将time_t解释为旧的32位time_t ，则可以定义_USE_32BIT_TIME_T 。 这样做会导致ctime评估为_ctime32 。 建议不要这样做，因为您的应用程序可能在2038年1月18日之后失败，并且在64位平台上不允许 
 
 
 现在定义_USE_32BIT_TIME_T只影响C头的编译方式，而且由于MinGW提供了自己的C头，MinGW可能不支持这个。 快速检查MinGW的time.h发现它确实存在，因此使用-D_USE_32BIT_TIME_T编译器选项来定义此宏的简单解决方案。 

(I don't know if I deserve credit for the answer, since I wouldn't have been aware of what the problem was without Harry Johnston's and indiv's comments, but I'll try to expand on the comments into a full answer.)
 
As indiv explained, the reason why makedefs.exe crashes is because ctime returns NULL. Normally you wouldn't expect ctime to do this, so we need to check the documentation find out under what circumstances it will return an error. Since MinGW is being used to do the compiling we need to look at Microsoft's Visual C++ documentation. This is because MinGW doesn't have it's own C runtime, it just uses Microsoft's.
 
Looking at at the Visual Studio C Run-Time Library Reference entry for ctime we find:
 
 
 
Return Value
 
 
A pointer to the character string result. NULL will be returned if: 
 
 
 
  
time represents a date before midnight, January 1, 1970, UTC.
 
  
If you use _ctime32 or _wctime32 and time represents a date after 03:14:07 January 19, 2038.
 
  
If you use _ctime64 or _wctime64 and time represents a date after 23:59:59, December 31, 3000, UTC.
 
 
 
 
Now it's pretty safe to assume the original poster hasn't set his system clock to a time far into the future or long in the past. So why would ctime be using the wrong time? Harry Johnston pointed out that the code was using long instead of time_t to store time values in. This isn't too surprising. Nethack is really old code, and originally Unix stored its time in long values, using time_t for time values came later. Nethack would've had to be dealing with old systems that didn't have time_t for a significant chunl of its active development period.
 
That explains why the Nethack source is using the wrong type, but it doesn't quite explain why it's passing the wrong value to ctime. The fact we don't see a description of the return value for ctime itself, just _ctime32 and _ctime64 gives us a clue. If time_t is a 64-bit type, then using long instead will be a problem. On Windows long is only 32-bits, so it would mean ctime is being passed a number that's one part time value, one part random bits. Reading on in the documentation confirms this is the case, and gives us a possible solution:
 
 
 
ctime is an inline function which evaluates to _ctime64 and time_t is equivalent to __time64_t. If you need to force the compiler to interpret time_t as the old 32-bit time_t, you can define _USE_32BIT_TIME_T. Doing this will cause ctime to evaluate to _ctime32. This is not recommended because your application may fail after January 18, 2038, and it is not allowed on 64-bit platforms
 
 
Now since defining _USE_32BIT_TIME_T only affects how the C headers are compiled, and since MinGW supplies it's own C headers, it's possible that MinGW doesn't support this. A quick check of MinGW's time.h reveals that it does, so the simple solution to use the -D_USE_32BIT_TIME_T compiler option to define this macro.