Is the term “compiler reliability” an oxymoron?

Go To Last Post
8 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

As I was rereading an old thread, this question came to mind – how could an algorithmic object like a compiler have reliability? A compiler is a software tool that always produces the same results for a given set of code. The concept of reliability seems incongruous to the concept of compiling. Yet, I often see reference made to the comparative reliability of compilers.

I know that objects like my car have reliability and that embedded software, with all of its temporal variability, can have this attribute. Processes too can have reliability and I often see the development process for software described as being reliable. However, this concept seems to go too far when it is attributed to compilers. It is like saying that the ratio of a circle’s circumference to its diameter is reliable.

Perhaps regulation has something to do with this misnomer. Standards are often used to control the development of embedded software and reliability is questioned during audits. Can we defend the reliability of our compilers?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

First, define what you mean by "reliability".

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:
always produces the same results for a given set of code

I think this here is the misstep -- you're restricting your domain to a fixed
single input sample, when a more relevant domain is "all possible programs",
or perhaps "all possible sequences of ASCII characters". A compiler's reliability
is measured over possible inputs in the same way that a car's reliability is
measured over time. I suppose an analoguous domain-limitation might be "Is
my car reliable at a certain instant?".

A compiler is a program with input and output and a set of rules (ANSIx3.9 e.g.)
which describes the rules for the output based on certain properties of the input.
(Ignoring actual compiler program "crashes",) a compiler is "reliable" to the
extent it faithfully produces output in accordance with these rules for all possible
inputs. (Yes, one possible output is "Not a valid program in this language".)

And just to muddy things (:-)): It is actually Not a requirement that a compiler always
produce the same output each time it is run on a given input; it's merely required
to produce output according to the rules, which provide considerable latitude.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

To me, the word ‘reliable’ has a temporal dependence. One can only speak of relying on something from repeated application. The word ‘accuracy’ is more appropriate when discussing compilers as it does not have a temporal dependence and embodies the concept of correctness or freedom from errors. I believe that when we worry about compilers we are actually worrying about errors in the output; not about differences in the output of a complier over multiple applications on the same input code.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:
To me, the word ‘reliable’ has a temporal dependence.

Given this definition, then I have to agree with your original thesis; however, I
don't agree that this definition is either useful or usual as applied to batch-style
software. (In rhetorical terms, you've "defined the question out of existence".)

Also, since I'm feeling pedantic this morning (:-)), I'll point out that what you've
described isn't really an "oxymoron" since even by your definitions "compiler"
and "reliability" aren't in conflict, merely unrelated. Perhaps "vacuous" or some
such?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

You may have nailed the problem here. Perhaps we should restrict the use of ‘reliability’ to reactive software. Software without temporal consequences, like batch-style, could be qualified with ‘accuracy’ or ‘correctness.’

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hi, geneo,

"reliability" - your issue sounds, as if you had recently a small talk wth a young (i.e. unexperienced) risk manager.

What to tell this unexperienced risk manager?

If the discussion should be restricted to reliability of the compiler itself, we might get lost in discussing the question "how reliable can a compiler be facing the excellent reliability of Microsoft products?"

My solution for discussions with my customers:
1. I consider the compiler to be a tool in the hand of me, the programmer.
2. I am the one, whose responsible to listen to my customer, to analyse the given task correctly and to deliver a piece of hard+software, which fulfills the task.
3. I can rely only on my own work, and I know, how often I detected errors in my thoughts.
4. I have to test my piece of hard+software in the field. I have to consider possible errors, how to detect them by testing. No compiler, no piece of software can do this for me.
5. How reliable is the management method of risk management anyhow? What are the risks in risk management itself? How can the risk manager proof, that the results of his work are free from any errors? (I believe: If someone goes to dance, but uses his eyes only to look for pitfalls on the dancing floor, catastrophees and errors, his attitude guarantees that his girl will loose her initial interest in him. Should a taxi driver tell me, he concentrates his thoughts on the possible car crashes, I would never join his taxi. I'm responsible to do the things carefully. I consider "carefully" as: Highest priority: Keep the success in my mind. But be aware about anything, which might be danger to this success.)

Summary: As the work of programming is a complicated and complex process, as I experienced a lot of failures with my windows operating system, the reliability of the programming task relys not on the reliability of the compiler alone, but on the competence of the programmer.

Ciao
Wolfgang Horn

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Like the old joke, if your only tool is a hammer every problem looks like a nail, I suspect reliability experts relate all problems to reliability whether it makes sense or not. Risk managers seem to prefer large, cumbersome tools and reliability is a favorite. I fervently wish that they would have more respect for compilers and for the people that use them.