Some IAR compilers have an horrendous year-2000 bug. It took me about 30 minutes to disassemble one of their compilers and track down what they’d done wrong.
Basically, for some reason I don’t have the inclination to figure out, all file-open and file-close operations go through one of their own weird routines that wraps around the POSIX open() and creat() functions, which are themselves wrappers for the Windows equivalent. As part of this pantomime the date stamp is obtained. What they’re actually doing is loading the date stamp year portion (which is the year offset from 1900) with 100 before making the call and checking to see it isn’t still 100 when it returns. If it is, they assume that the open/creat process has failed somewhere because no new year was loaded. The only snag, of course, is that 2000 is actually 100 years from 1900 – someone obviously assumed it’d wrap to 00.
You can easily patch this problem out by changing the rogue value to 0xff or similar if you feel so inclined. To find it just start with the OpenFile() dynamic link in the executable (we’re talking Win32 exe here), look to see what calls it. This looks like a standard library the open() function. Then look to see what calls that (the weird IAR function). Inside look for where 100dec is loaded into a structure and replace it with something else. Don’t be tempted to play a little trick on your colleagues and time-bomb it for another year in the future.
I’d be most interested if someone with access to the source code could confirm or reject this explanation – in confidence of course!
(Originally published as www.fjl.co.uk/answers/faq/q3a.htm)