sugoll (sugoll) wrote,

  • Mood:

Bugs in compilers

Having read this, I felt compelled to dig this out, after having written it a few years ago. Yes, I work for a compiler company.

Submitting Compiler Bug Reports
If you ever have to submit a bug report to the Compiler Teams, there are several pitfalls to watch out for. This document explains the best way to go about it - all the handy tips in one place.

Compiler people are busy
The first thing to remember is that, just like you, the Compiler people have lots of work, and are very busy people, so anything you can do that saves them time is good. It'll cheer them up, and get you a better response, faster.

Compiler errors show up quickly
Because of the nature of compilers, the bugs show up very quickly after release, and lots and lots of users all report the same old bugs to the Compiler team. This explains why they are so jaded and grumpy: they'll have seen the bug reported lots of times before you encounter it. Pretty much, you only need to tell them that there's a problem, and they'll send out a fixed compiler straight away.

Keep it short
The Compiler team get a lot of bugs every day, and don't have time to read through your life story, so remember to keep the bug reports as short as possible. Don't get bogged down in explaining all the little details about which options you used or what you were compiling, or how. These only waste time.

Which tools?
You know those little messages the compiler gives out when it breaks? The Compiler people see those a lot. So if you do feel the need to quote an error message in your report, then the Compiler people will be able to determine which version of the compiler you're using, and on which platform, so you don't need to bother looking that up. Besides, if there's any doubt, they can check which licence you've got, and which issues you're reported before. Remember, keep it short!

Code fragments
If you absolutely have to take up everyone's valuable time by giving an example, then the best thing is to cut'n'paste the bit of your source file that causes the problem - preferably into a Word document, which you can then attach to your problem report. If you include the whole file, the Compiler people won't have time to look through finding the

A picture speaks a thousand words
One great way to save time is just to dump a screenshot of the point of failure into the problem report. This shows the Compiler people everything they need to know in one, simple, 80MB image. They'll be delighted with this thoughtful gesture.

Be direct
The Compiler people are professional engineers (albeit jaded and grumpy, as previously mentioned), so they aren't put off by a bit of straight talk. Plus, flowery language and unnecessary politeness merely confuses the issues. Tell them exactly what you think of the product. How else will they know what needs improving.

Don't repeat yourself
If you've submitted issues before, don't go over the old ground. Skip all the stuff about tool versions, platforms, your projects, and other problems you've been having, and get to the point. They'll remember all of the above from the last report you submitted, sixteen months ago to a different team.

While you're at it...
One good way to save time is to submit several problems at once, since this saves the Compiler team from having to skip to another page in their web browser. If you've got crashes, language problems, strange run-time results, and enhancement suggestions, just put them all in the same mail message. Heck, bung in a few comments on the GUI, the simulators, and the colour scheme of the packaging the product came in, too - save time for everyone. Just be sure to put your most important issue right at the end, as a one-liner.

It only takes a few minutes to correct a source file and rebuild a program, so as long as you've kept everything brief, there's no reason why you shouldn't get a working patch within 24 hours of submitting your problem, including weekends and Christmas. If you don't get a patch that quickly, it's probably because you were too verbose; try again, with less information.

Redundancy is good
If you're dealing with us through a sales person, then it's good practice to submit the report both through the sales droid, and through Support directly. And if you know a Director or two, get them in the loop too. If you happen to know someone at our company - or if you just have their email address - then send the report to them; it'll get to the right person faster than if you have to go through the Support alias, which only exists to insert delays into the process.

Be educational
Although the Compiler people are experts (and professional, jaded, etc.) even they aren't as good a C programmer as you. Occasionally, they make mistakes, so when you find cases where the compilers deviate from the ANSI standard - an international standard based on the behaviour of Microsoft VisualC++ - then it's always helpful to explain the way things should work. It'll help other customers in the future, so in this case, it's actually good to be verbose and detailed.

Ask for a copy of our certification
All our compilers are fully certified to the highest standards, with full formal mathematical proofs to show how every resulting executable is accurately generated from the original C source. If you don't understand any of the responses that come from the Compiler teams, then just ask for a copy of the full two-page proof of the optimiser's behaviour. It'll make everything clear.

We're here to help
If you're new to C programming, or if you've got some doubts about how to code that interrupt handler, then by all means ask our experienced support team. They'll give you megabytes of carefully tailored code to match your requirements as quickly as possible. Heck, if you've got a class assignment in Visual Basic, ask the C compiler team. They'll be delighted to write it for you.
Tags: computers
  • Post a new comment


    default userpic
    When you submit the form an invisible reCAPTCHA check will be performed.
    You must follow the Privacy Policy and Google Terms of use.