3APA3A wrote: > 11.10.2006 Vendor response: > > "We believe this is not a security vulnerability but in fact a > deliberate security feature to mitigate problems with invalid data > propagating through the system". Proving once again that MS has ordered all of it's copies of K&R burned, and will not declare victory until MS C[++] is entirely abstracted from all existing standards and other implementations? > [...] incorrectly behave for a time_t argument larger than or equal > to _MAX__TIME64_T (representing January, 1 3000 00:00:00). According to > MSDN documentation, time functions must indicate error by returning NULL > pointer or EINVAL (depending on function class) and must not invoke any > invalid parameter handler. Instead, time function calls invalid > parameter assert()-like macro, terminating calling application and > creating Denial of Service condition for calling application. Considering that since the inception of these functions they were *unbounded* (the entire 32bit time_t space can be trivially represented), and that the MSC 8.0 change to 64 bit time_t is a *Microsoft* imposed *default* behavior, and that they don't cite MAX_TIME_T, the response seems especially foolish.
