Silverfrost Fortran: The World's Best Runtime Checking
CHECKMATE offers the programmer the ability to check the correctness of their code dynamically
at runtime. Combined with the excellent diagnostics provided by the compiler itself Silverfrost Fortran with
CHECKMATE can dramatically improve code quality. In a test by an established Fortran vendor,
FTN95 catches 96% of errors. Other tests by independent bodies put Silverfrost Fortran out in front for
error checking. For more details of these tests and for source code see the following link:
Detects Programming Errors
It is very easy to make programming errors in Fortran which are not picked up by the compiler and which go on to produce undefined errors later during execution. FTN77 programmers have been able to use the /CHECK and /UNDEF options to check out their programs thoroughly as they execute. This facility has found many, many programming errors, and some of our customers specify that Fortran code must run in /UNDEF mode as part of their internal quality assurance. Now this facility is available in Silverfrost Fortran FTN95. Here are just some of the things that are checked for you dynamically:
- Check that subroutines/functions are called with the right number of arguments of the right type. This check works even in traditional Fortran programs which have not used the INTERFACE statement or in programs constructed from several files with inconsistent INTERFACE statements
- Checks that array subscripts do not go out of bounds. FTN95 performs this check even for arrays declared with bounds of (*) or assumed-size or ALLOCATE'd arrays. The only requirement is that in the case of argument arrays the caller must also have been compiled in CHECK mode (normally entire programs are compiled in CHECK mode anyway).
- Checks that integer and floating point calculations do not overflow
- Using the /UNDEF option you can check that a program does not use variables before they have been defined. Although the compiler can warn in simple cases, often it is only at run-time that this problem can be detected. The undefined check works with everything - common data, local variables, allocated data, even individual elements of an array (which can be partially undefined)
- Checks that arguments passed to routines as constants are not treated as variables and altered by the callee (or anything that it calls). The effect of doing this is normally very insidious, usually the constant is overwritten, corrupting the program at a later point
- Checks that whole array operations on arrays where conformability cannot be checked at compile time are in fact conformable
- Checks that unavailable objects - such as arguments that are not available through the ENTRY point in use, or absent optional arguments, or unallocated ALLOCATABLE objects - are not in fact used
- Checks that references are not made through 'dangling' or unassigned pointers
Needless to say, checking for all these error conditions can slow down program execution considerably. However, once a program has been debugged in this way, it is only necessary to recompile without these options (or with the /OPTIMISE option) to produce fast production code.
- Array bounds violations
- Zero trip DO loops
- Calling a Fortran routine with an incorrect number of arguments
- Calling a routine with incorrect argument types
- Overwriting constant data
- Use of variables before they have been assigned a value
- Floating point overflows
- Calling a Fortran function as if it were a subroutine
- Passing an array to a Fortran subroutine where the array is too small
- Passing an array where the lower bound is greater than the upper bound
- Use of dangling pointers
CHECKMATE can be turned on and off with the use of compiler switches or configuration options within Visual Studio. CHECKMATE is available for use with 32-bit, 64-bit and .NET projects.