Tag: IAR

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)

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)