Re: Compiler quality

[Georg Bauhaus <rm.dash-bauhaus@futureapps.de>]

anon schrieb:
> Your not understanding the concept finite for programs. And this explanation 
> does not the finite concept of hardware.

(Just for clarity, a program text is finite by definition.)

Please, could you give the cardinality of the set of 4kB-Ada programs
that a given compiler, such as GNAT 3.15p, can process, and decide,
on a PC of 1GB RAM, 200GB file space, within 1h?  I'd like to be
realistic, so I'll be glad to learn the factor F and an exponent
N in F*10**N.

How does this number compare to the cardinality of the set of Ada
programs of 6_000 .. 10_000 SLOC?  (That's roughly the size
of a book.)

How long does it take to demonstrate that a single Ada program
should map to one sequence of CPU instructions? (Else we have
not a single, complete, test case, because a compiled program may
just happen to produce expected results in some cases.)



> An example is like using the following statement
> 
>                    X := Sin ( A ) + Cos ( W ) ;
> 
> do use need to also create the statement
> 
>                    X := Cos ( W ) + Sin ( A ) ;
> 
> to prove that a simple mathematical statement is BUG free.  The answer is no! 
> So a vendor may use one not both to perform the test, to say the statement 
> checking is BUG free.  

Good example, because the order of FPT operations may affect
the result of the statements. So the answer is yes, you may
have to test both statements, with all kinds of inputs for W and A...
(Note that I'm not saying you need all *possible* inputs, just
those that one needs within the given FPT framework. They have been
named in extensive literature.)


> And using every statement that can be created is just overkill, but it can be 
> done. There are places in a compiler that are tested to the point of being 
> BUG free and that number of testing is finite. 

By your previous argument about bug free compilers,
a compiler is therefore the same as a place in a compiler,
as far as testing goes...