The passing of parameters to procedures within a programming language allows the user great freedom in the design of procedures. A general purpose algorithm may be constructed which takes various parameters as input and produces various results. depending upon the input values . The concept of parameter passing is embedded within most programming languages in some manner, either by explicit parameter identifiers as seen in FORTRAN-type calling sequences or by implicit parameter identifiers as seen i n stack-oriented languages . Interpreter-based programming languages make use of variants of both of these types, such as APL's argument lists, which get pushed on a stack when the function is invoked .

1. -18 -
technical contribution s
Parameter Validation For Software Reliability
Glen E . Alleman
Fluor Corporatio n
3333 Michelson Dr .
Irvine, CA 9271 5
Abstract - This paper presents a method for increasing softwar e
reliability through parameter validation . Existing systems ar e
examined and a proposed technique is presented to aid in th e
static parameter validation of RATFOR programs .
Introduction
The passing of parameters to procedures within a programming
language allows the user great freedom in the design of pro-
cedures . A general purpose algorithm may be constructed which
takes various parameters as input and produces various result s
depending upon the input values . The concept of parameter passin g
is embedded within most programming languages in some manner ,
either by explicit parameter identifiers as seen in FORTRAN-typ e
calling sequences or by implicit parameter identifiers as seen i n
stack-oriented languages . Interpreter-based programming language s
make use of variants of both of these types, such as APL's argumen t
lists, which get pushed on a stack when the function is invoked .
Although the concept of parameter passing provides a great dea l
of flexibility for the language user, it also is the source o f
many programming errors . The main cause of these programmin g
errors occurs when languages require the user to explicitly stat e
the parameter TYPE when referencing the parameter . Although some
language processors allow mixed mode operations during run tim e
(REALs and INTEGERs mixed in a statement) the passing of a mis -
TYPEd parameter usually causes a failure of the procedure durin g
run time . This problem is seen in compiler-based systems due to
the static nature of TYPE declarations during compilation . In an
interpretive environment, dynamic TYPE changes may take place t o
relieve this restriction . In this paper I will only address

2. -19 -
compiler-based languages and specifically ones which exhibit poo r
parameter validation features . Additionally I will discuss onl y
the parameter passing techniques involved with SUBROUTINEs . The
problem faced with parameter validation within the context o f
FUNCTION invocations is a separate subject .
An Overview of Parameter Validatio n
The concept of parameter validation does not exist in all compiler -
based languages . FORTRAN, for example, does not validate th e
parameters declared in the argument list for anything except the
name's length . More modern languages such as PASCAL and EUCLI D
allow explicit declarations to be made in the parameter list an d
validate the TYPE conversion operations during run-time . Languages
such as ALGOL 60/68 also allow explicit declarations of paramete r
types but do not perform the validation until run-time .
Functional Requirements forParameter Validation
In designing programming languages the compiler writer usuall y
takes the axiom of "never put off till run-time, what you can d o
at compile time" [Gries 71] .
It is not always possible for parameter validation to be per -
formed in languages which allow external modules to be construc -
ted independently of each other and "bound" at a later time . The
solution to the validation of "unbound" variables is to postpon e
the validation until run-time . The problem produced by th e
run-time checking of parameter TYPES is that the errors passed t o
the run-time environment could have been detected during compila -
tion, thus wasting resources recompiling source code after a n
error has been detected . If the major amount of parameter valida -
tion, or for that matter any static error analysis, can be per -
formed prior to compilation, expensive resources may be preserve d
and increased throughput will occur .
For parameter validation to be performed within the context of a
programming language, the language designer must allow for the
explicit specification of parameter TYPEs, validation of thos e
TYPEs during compilation and run-time and control structure s
which allow conditional branching on TYPE conversion or valida -
tion errors .
The specification of these capabilities in new languages is a n
easy task compared to the implementation of parameter validatio n
in languages not designed for such a feature . In the programmin g
language EUCLID [Popek 77] the author has set out to design a n
enhanced version of PASCAL which would allow the user to write

3. -20 -
verifiable programs . To this end the EUCLID designers embodied
the syntax of the language with TYPE-checking capabilities no t
found in the original PASCAL design [Wirth 73] . Not all language s
in use today had the opportunity to develop their syntax wit h
validation techniques built in .
Impacts on Software Design
If the programming language used to develop software does no t
provide parameter validation techniques, then the design an d
reliability of software systems using the language will be impac -
ted by the inability to validate parameters passed to procedures .
Errors produced during compilation and run time checking, due to
ill .-defined parameter declarations, may cause delays in th e
development cycle of the system . Since most of the software
written in the nonbusiness community is still performed in FORTRAN ,
the ability to validate parameters in a large body of softwar e
still does not exist . Approaching the solution to the problem o f
parameter validation in FORTRAN programs, several systems hav e
been developed which attempt to solve this problem [Bridges 76 ,
Thompson 75] .
A more direct approach is taken in the FORTRAN preprocesso r
RATFOR . RATFOR provides internal MACRO capabilities, which allo w
multiple arguments to be passed to the MACRO, which may in turn
be other MACROs . Utilizing RATFOR MACROs a technique will b e
presented which will allow software to be written which will ai d
in the validation of procedure parameter declarations in a stati c
manner .
Data Structure Referencing
The referencing of data structures by procedures is functionall y
dependent on the TYPE declaration of the data structure . I n
designing programming languages the author must make the choic e
between the security offered by full TYPE declaration (within a
suitable linguistic framework} and the simplicity offered by th e
flexible (but incomplete) classical TYPE systems . Some example s
of the classical TYPEing systems are seen in ALGOL 60, where the
TYPE procedure does not include the type of acceptable parameters ,
and in ALGOL 68, where the type reference ignores the fact that a
reference may be a dummy . PASCAL type unions (variants of recor d
structures) may be "unsafe" because of the possibility of errin g
on the current alternatives of the union [Cousot 77], i .e . ,
dynamically changing the declared type . In all of these languages
the problem of subscript range is not safely treated by the TYP E
concept . A major problem with FORTRAN in regard to subscrip t
validation during run-time is that most run-time subscript checkers

4. rely on the fact that the array being checked is of the correc t
TYPE or has not been EQUIVALENCEd to a second array of differen t
TYPE . In EUCLID formalized parameters may be declared whic h
explicitly denote the data structure TYPE . The passing of formal
parameters within EUCLID allows the dynamic changing of structur e
TYPE during run-time as well as the validation of these changin g
TYPES . It must be noted though that the implementation of thes e
dynamic TYPE validation techniques is a nontrivial task for th e
language designer .
There seems to be no solution to the run-time validation o f
FORTRAN data structures as long as the EQUIVALENCE statement i s
allowed . One existing system , [Bridges 76] forbids the use o f
EQUIVALENCE in an attempt to validate COMMON area declarations ,
and in general the use of such structures created by the EQUIVALENC E
statement leads to poorly maintainable code .
Parameter Validation In EUCLI D
The programming language EUCLID is an extension of Wirth's PASCA L
[Lampson 77] in which formal verification capabilities are imbedde d
within the syntax of the language [London 77] . EUCLID syntax
concepts have been borrowed from several other programming language s
such as ALPHARD [Wulf, London, Shaw 76], BCPL [Richards 69], CL U
[Liskov 76], GYPSY [Ambler 76], LIS [Ichbiah 74], MESA [Geschke 73] ,
Modula [Wirth 76] and the SUE System Language [Clark, Horning 73] .
EUCLID formally defines the parameterized TYPE by the followin g
rule :
ParameterizedTypeReference : . -
[containingVariable " ."] typeldentifie r
typeActualParamete r
/ "," typeActualParameter / ") "
For example :
PROCEDURE f(a :ARRAY 1 . . .n OF signedlnt) . . .
The ability to dynamically change the parameter TYPE is provide d
through the use of a PARAMETER keyword . "Each actual parameter
of the type for which PARAMETER appears is treated as though i t
appeared as an additional formal parameter of the procedure, an d
the appropriate parameter of the procedure is supplied in every
call ." [Lampson 77] . Thus :
TYPE Ta(n :unsignedlnt)=ARRAY 1 . .n OF Signedlnt ;
PROCEDURE f(a : Ta(parameter)) . . .

5. -22 -
Language Construct Limitation s
Compiler imposed parameter declarations provide flexible method s
of declaring data structure types and parameterizing them i n
arguments of procedures . The more formal restrictions imposed by
EUCLID provide a "secure" procedure production which when trans -
lated into PASCAL procedures produce "secure" PASCAL procedures .
The user of a programming language must make the decision as t o
what flexibility to trade off for secure software . According to
Wirth [Wirth 75], there appear to be three different motivations
behind the desire for variants in data structure architecture s
(dynamic variant in record structure) :
- The need for heterogeneous structures, in two main cases :
1) Static variants to describe classes of data which ar e
different yet closely related .
2) Dynamic variants, to describe objects whose component s
depend on a possibly changing state .
- Storage sharing (overlays) which imply the same storag e
area may be used for different purposes .
- Realization of implicit type transfer functions (unchecke d
type conversions) .
It is clear that PASCAL provides flexibility at the expense o f
security . Cousot [Cousot 77] shows that a compiler may report to
the user which constructs have been used in either secure o r
insecure ways .
Performance Considerations
In producing compilers which validate procedure parameters an d
data structure references, the computational overhead incurre d
may be large compared to compilers which provide no such checking .
At first glance, it would appear that the above statement i s
true ; however, no convincing analysis of this question can b e
made without data obtained from the execution of programs usin g
validation techniques .
If all parameter validations are performed during compilatio n
then run-time execution speed should be the same for unvalidate d
compilers . If the run time environment performs parameter vali-
dation it would seem reasonable that the actual validation proces s
could be disabled once the program was in production . Looking at
the overall development cycle, the compiler which provided static

6. -23 -
and dynamic parameter validation (with the ability to disabl e
dynamic validation) would provide a tool for increasing th e
productivity of software development .
RATFOR Parameter Validation
The availability of language features of the type provided b y
EUCLID or PASCAL are not readily accessible to the common user .
The majority of code written within the United States is i n
FORTRAN and COBOL . Neither FORTRAN nor COBOL provides a forma l
parameter validation capability, leaving open the problem dis-
cussed above .
The FORTRAN preprocessor RATFOR [Kernighan 76] provides a MACR O
capability which I propose to use in the construction of a syste m
which will statically validate parameters to RATFOR programs .
(The object code produced by the RATFOR compiler is FORTRAN IV . )
The MACRO processor in RATFOR allows the definition of macros b y
the following convention :
Define(Macro-Name, Macro-Definition )
The macro name must be a legal FORTRAN name token and the macr o
definition must be a legal RATFOR . or FORTRAN expression, or a
legal RATFOR MACRO . The macro definition process allows fo r
arguments to be passed to the macro in the form of dumm y
variables denoted by, $l,$2, . . .,$9, for example :
Define(BERGWERK , $1 = $2 + $3 )
When invoking the macro BERGWERK the following expansion occurs :
BERGWERK(A,B,C )
Expands to
A=B+ C
A macro to generate a parameterized procedure call has the func-
tional form :
Define(PROC,[Subroutine $1,$ 2
DCL $2] )
Define(DCL,[Substr $1,1 Substr $1,3] )
The macro Substr is used to extract the substring of a dumm y
argument starting at a specified position (it extracts tokens ,
not characters) . An example of the parameter declaration expan-
sion is :
PROC(BERGWERK,(INTEGER :A, REAL :B, COMPLEX :C)

7. -24 -
Which expands to
SUBROUTINE BERGWERK(A,B,C )
INTEGER A
REAL B
COMPLEX C
Once the source RATFOR code has been generated with the PRO C
macro used in place of the normal subroutine declaration sequence ,
the process of validating the arguments may take place . The
following restrictions are placed on the generation of RATFO R
programs :
- All variables must be declared .
- No EQUIVALENCE statements are allowed .
- The passing of FUNCTION names by way of EXTERNAL state -
ments is forbidden .
The following algorithm is then used to process all source files ,
and determine if an illegal parameter specification has been mad e
or referenced :
[1 .0] Gather all source files into one file .
[2 .0] Build a calling sequence tree (or list) by detecting the
FORTRAN calling protocol, CALL SUBR(ARG1, . . .,ARGn) .
[2 .1] The declared types are found by locating the declaratio n
statement associated with the argument in the callin g
protocol .
[2 .2] Each node of the calling tree (or entry in the calling
list) will contain the parameters used in the callin g
sequence and their declared types .
[3 .0] Build a list of procedures contained in the master source
file .
[3 .1] The procedure list will contain the entry name, the para-
meters declared in the procedure and the declared types o f
these parameters .
[4 .0] Compare the "called" parameter types of a specific procedur e
with the declared parameter types found in the procedur e
list .
[4 .1] Record all differences between the called parameter declara -
tions and the explicit declarations produced by the calle d
procedure .

8. -25 -
Example of RATFOR Parameter Validatio n
Given the following procedure declarations in RATFOR :
PROC(ALPHA, (INT :ARG1, INT :ARG2) )
BEGIN
(Body of ALPHA )
END
PROC(BETA, (REAL :ARG1, REAL :ARG2) )
BEGIN
(Body of BETA )
END
PROC(GAMMA, (REAL :ARG1, INT :ARG2) )
BEGI N
(Body of GAMMA )
END
With a main procedure making calls to ALPHA, BETA and GAMMA :
PROC(BERGWERK )
BEGI N
REAL X
REAL Y
INTEGER Z
CALL ALPHA(X,Y )
CALL BETA(X,Y )
CALL GAMMA(X,Z )
END
The following lists describe the argument declarations, calling
sequences, local declarations and Parameter Declarations :
(Local DCL) (Subr) (Parameter DCL )
(R :X)(R :Y)(I :Z) [BERGWERK] ( )
() [ALPHA] (INT)(INT )
() [BETA] (REAL)(REAL )
() [GAMMA] (REAL)(INT )
The procedure calling sequence table is :
(Routine) (Calls) (With these parameters )
[BERGWERK] [ALPHA] (REAL)(INT )
[BERGWERK] [BETA] (REAL)(REAL )
[BERGWERK] [GAMMA] (REAL)(INT)

9. -26 -
A comparison can now be made between the called parameters of a
procedure and the internal declared parameters to determine if a n
error has been made in the calling sequence . One calling sequenc e
error has occurred in the above example ; the call to the procedur e
ALPHA has been made with a REAL and an INTEGER when the paramete r
declarations with ALPHA were INTEGER and INTEGER, respectively .
Impacts on Software Design Methodologie s
Formal parameter validation should provide another tool by whic h
the software designer can gain confidence about the reliabilit y
of the code produced . By employing parameter declaration and
subsequent parameter validation, the source language code will b e
enhanced by :
- Increased reliability .
- Increased readability due to the explicit declaration s
provided .
- Increased maintainability due to the increased readability .
- Further progress toward the goal of program correctnes s
and validation .
In the realm of FORTRAN software the use of preprocessors with
MACRO capabilities such as RATFOR provides a technique for increas-
ing the overall software reliability through the structuring o f
FORTRAN source code as well as parameter validation .
In languages such as EUCLID and PASCAL the ability to staticall y
and dynamically validate procedure parameters leads to increase d
software reliability as well as increased productivity in th e
coding and check-out phase .
Trends In Parameter Validation
A trend is occurring in many programming languages to limit th e
number of explicit variable types allowed, restrict the contro l
structures available and restrict the interactions allowed betwee n
procedures . All of these trends point to the solution of th e
major problems found in early programming languages - ill-define d
syntax, ill-defined semantics and uncontrolled data structures .
The task of parameter validation fits into the scheme of reducin g
the complexity of languages and furthering the generation o f
clear concise programs .

10. -27 -
REFERENCE S
[Ambler 76] A . L . Ambler, et al, "GYPSY : A Language for Speci -
fication and Implementation of Verifiable Programs," Sigplan
Notices, Vol 12, No . 3, March 1976 .
[Bridges 76] R . F . Bridges, "Bridges : A Tool for Increasin g
Reliability of References to FORTRAN Variables," Sigplan Notices ,
Vol 11, No . 7, September 1976 .
[Clark et al 73] B . L . Clark and J . J . Horning, "Reflections on a
Language Designed to Write an Operating System" Sigplan Notices ,
Vol 8, No . 9, September 1973 .
[Cousot 77] P . Cousot and R . Cousot, "Static Determination o f
Dynamic Properties of Generalized Type Unions," Sigplan Notices ,
Vol 12, No . 3, March 1977 .
[Geschke 75] C . M . Geschke and J . G . Mitchell, "On the Proble m
of Uniform References to Data Structures," Sigplan Notices ,
Vol 10, No . 6, June 1975 .
[Grier 71] D . Cries, Compiler Construction for Digital Computers ,
John Wiley and Sons, 1971 .
[Ichbiah 74] J . D . Ichbiah, "The System Implementation Language
LIS," CII, 68 route de Versailles, 78430 Louveciennes, Franc e
(December 1974) .
[Kernighan 76] B . W . Kernighan and P . J . Plauger, Software
Tools, Addison-Wesley, 1976 .
[Lampson 77] B . W . Lampson, et al, "Report on the Programmin g
Language EUCLID," Sigplan Notices, Vol 12, No . 2, February 1977 .
[Liskov 76] B . Liskov, "An Introduction to CLU," Computation
Structures Group Memo 136, MIT (February 1976) .
[London 77] R . L . London, et al, "Proof Rules for the Programming
Language Euclid," to appear (1977) .
[Popek 77] G . J . Popek, "Notes on the Design of EUCLID," Sigplan
Notices, Vol 12, No . 3, 1977 .
[Richards 69] M . Richards, "BCPL : A Tool for Compiler Writin g
and Structured Programming ."

11. -28 _
[Thompson 75] E . W . Thompson and R . F . Bridges, "A Module Interfac e
Specification Language, "Proceedings of 12th Design Automation
Conference, Boston, Massachusetts, June 1975 .
[Wirth 73] N . Wirth, "The Programming Language PASCAL," Acta
Informatica 1, pp . 35-63 .
[Wirth 76] N . Wirth, "Modula : A Language for Multiprogramming, "
Institut fur Informatik, ETH, Ch 8092 Zurich (March 1976) .
[Wirth 75] N . Wirth, "An Assessment of the Programming Languag e
PASCAL," Sigplan Notices, Vol 10, No . 6, June 1975 .
[Wulf et al 76] W . A . Wulf, M . Shaw, and R . L . London, "An
Introduction to the Construction and Verification of ALPHAR D
Programs," IEEE Transactions of Software Engineering SE-2, 4 ,
pp . 253-265 .