If you check out IAR’s web site you’d be forgiven for thinking that IAR compilers had no problems with dates past 2000. You’d be quite wrong – they’ve got more Y2K bugs than a termite hill and they’re too shy to tell you about them.
It’s true that most tools since late 1998 are fixed but pretty much all the older ones have the same set of funnies. Most listings will be dated 22/Jun/102; the ‘C’ __DATE__ macro has a similar amusing effect, and so does the DATE 6 equivalent in the assembler. Embarrassing but not fatal, although it would have been nice if they’d owned up to the world on their web site.
However, if you’re using the IAR debug object format, UBROF, you may be in for a much worse surprise. The UBROF format has a header containing the link time and date. This is also messed up, such that several debuggers are known to reject files linked post-2000 due to invalid header information. This isn’t a bug in the debugger
IAR’s solution is to upgrade. Well they would say that, wouldn’t they? You don’t fancy jumping your compiler version on three years? Rather stick with the devil you know? Then download iarfix.com now. Simply run this on your output file after the linker has done its stuff and it’ll fix up the header and anything else it can find that might be wrong with it. You can even give it a wildcard file spec if you have a directory full of stuff that chokes your debugger.
It’s not supported, not guaranteed and not properly tested but you’re welcome to try it. If it doesn’t do it for you then let me know and I’ll think about updating it – but there have been no complaints in the last twelve months. If you’re the type that really must have a support contract for ISO9000 reasons then I’ll sell you one for £1000 a year and make damn sure it works for you. Still interested? I thought not. Enjoy!
As a final kick in the teeth, IAR managed to release a few disastrous ‘compliance’ updates, some of which have made it into the wild. They fix the embarrassing listing problems but, for some inexplicable reason, stop and catch fire when asked to read or write to a file with a year stamp of 2000 (including ones that it has just opened itself). Was a complete mystery why how or why they could have coded their file handling code in such a way that the date mattered, and even more of a mystery why they didn’t notice it when they tested it. Nice once guys! If you wait until 2001 then these rogue tools start working again without any apparent problems.
I’ve now disassembled one of their iffy compilers if anyone’s interested What on earth did IAR do to break their compiler?
Finally, if anyone from IAR in Sweden is reading this and thinks I’m being a bit hard on them – think about this: If you disclosed this information on your web site instead of pretending that everything was okay then none of this would have been necessary. Your customers are going to find out soon enough anyway, and when they do you’re going to look even worse.
(Originally published as www.fjl.co.uk/answers/faq/q3.htm)