Parameter Validation for Software Reliability


Published on

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 .

Published in: Technology
  • Be the first to comment

  • Be the first to like this

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

Parameter Validation for Software Reliability

  1. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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 .