CN108446122B

CN108446122B - Parameter consistency verification method and device

Info

Publication number: CN108446122B
Application number: CN201810239209.1A
Authority: CN
Inventors: 庄为; 李诗宇; 许佳丽
Original assignee: Bank of China Ltd
Current assignee: Bank of China Ltd
Priority date: 2018-03-22
Filing date: 2018-03-22
Publication date: 2021-10-29
Anticipated expiration: 2038-03-22
Also published as: CN108446122A

Abstract

The application provides a parameter consistency verification method and device, which are used for acquiring the information of a form parameter and an actual parameter from a source code, acquiring the result of whether the length of the form parameter is the same as that of the actual parameter, and outputting the position information of the form parameter and the actual parameter in the source code under the condition of different lengths, so that a programmer can be prompted and can correct in time, and the problem of out-of-range memory access in the operation process is avoided. Compared with a manual checking mode, the method has higher accuracy.

Description

Parameter consistency verification method and device

Technical Field

The present application relates to the field of electronic information, and in particular, to a parameter consistency verification method and apparatus.

Background

In source code written in the COBOL language, a form parameter (abbreviated as a "profile") refers to an entry parameter defined in a subroutine (called program). The essential parameter (real parameter for short) refers to a parameter transmitted when a main program (main calling program) calls a subprogram.

In source code, the arguments may be of different lengths due to programmer error, etc. In this case, during the compiling and running process of the source code, the problem of memory access boundary crossing caused by inconsistent memory space occupation of the parameters can occur.

In the prior art, the source code is manually reviewed to avoid the problem, but omission easily occurs in the method, so that the problem of boundary crossing of memory access caused by inconsistent memory space occupation of parameters cannot be completely avoided.

Disclosure of Invention

The application provides a parameter consistency verification method and device, and aims to solve the problem that memory access is out of bounds due to inconsistent memory space occupation of form parameters and actual parameters.

In order to achieve the above object, the present application provides the following technical solutions:

a parameter consistency verification method, comprising:

acquiring length information of the form parameter and the actual parameter from a program of a source code;

comparing whether the length of the form parameter is the same as that of the actual parameter and generating a comparison result;

and if the comparison result indicates that the length of the parameter is not the same as that of the parameter, outputting the position information of the parameter and the parameter in the source code.

Optionally, the obtaining of the length information of the parameters includes:

storing the length information of the parameters in a preset data table, wherein the data table comprises: an E _ PARM _ LIST table and a C _ PARM _ LIST table;

the E _ PARM _ LIST table is used for storing the length information of the parameters of the entrance of the program;

the C _ PARM _ LIST table is used for storing argument length information in CALL statements in the program.

Optionally, the E _ PARM _ LIST table is further configured to:

and storing the unique number allocated to the parameter, the unique number of the entrance of the program to which the parameter belongs, the sequence number of the parameter and the name of the parameter.

Optionally, the C _ PARM _ LIST table is further configured to:

and storing the unique number distributed to the real parameters, the unique number of the CALL statement in the program to which the real parameters belong, the sequence number of the real parameters and the names of the real parameters.

Optionally, the data table further includes:

a PGM table for storing information of the program in the source code;

PGM _ ENTRY table: the entrance information is used for storing the program;

CALL _ STMT table: the information is used for storing the information of the CALL statement in the program;

wherein, the PGM table includes a unique number assigned to the program, a name of the program, and a storage path of the program;

the PGM _ ENTRY table includes: assigning a unique number to an entry of the program, a unique number of a program to which the entry of the program belongs, a sequence number of the entry of the program, a name of the entry of the program, and location information of the entry of the program in the source code;

the CALL _ STMT table includes: the unique number allocated to the CALL statement, the unique number of the program to which the CALL statement belongs, the sequence number of the CALL statement, the position information of the CALL statement in the source code, the name of the program called by the CALL statement, the name of the entry of the program called by the CALL statement, and the dynamic CALL identifier.

Optionally, the data table further includes:

a DYN _ CALL _ MAP table and a DYN _ CALLED _ PGM table;

the DYN _ CALL _ MAP table is used for storing the relation between CALL statement variable names and possible program names, wherein the variable names are stored in the target field of the CALL _ STMT table; the possible program names are stored in a calledjpgm field of the DYN _ CALLED _ PGM table;

and the DYN _ CALLED _ PGM table is used for storing possible values of variables of the possible program names in a dynamic calling statement.

Optionally, the comparing whether the length of the parameter is the same as the length of the real parameter includes:

searching the length of the form parameter of the program from the data table, searching and calling a call statement of the form parameter according to the corresponding relation between the data tables, and comparing whether the length of the real parameter in the call statement is the same as the length of the searched form parameter;

and/or searching the length of the real parameter in the call statement of the program from the data table, searching the form parameter called by the call statement through the corresponding relation between the data tables, and comparing whether the length of the form parameter called by the searched call statement is the same as the length of the searched real parameter.

A parameter consistency verification apparatus, comprising:

the acquisition module is used for acquiring the length information of the form parameter and the actual parameter from a program of a source code;

the comparison module is used for comparing whether the length of the form parameter is the same as that of the actual parameter and generating a comparison result;

and the output module is used for outputting the position information of the parameters and the parameters in the source code if the comparison result indicates that the lengths of the parameters are different from the length of the parameters.

Optionally, the obtaining module is specifically configured to:

Optionally, the E _ PARM _ LIST table is further configured to:

Optionally, the C _ PARM _ LIST table is further configured to:

Optionally, the data table further includes:

a PGM table for storing information of the program in the source code;

PGM _ ENTRY table: the entrance information is used for storing the program;

Optionally, the data table further includes:

a DYN _ CALL _ MAP table and a DYN _ CALLED _ PGM table;

Optionally, the comparing module is specifically configured to:

According to the parameter consistency verification method and device, the information of the form parameter and the actual parameter is obtained from the source code, the result of whether the length of the form parameter is the same as that of the actual parameter is obtained, and under the condition that the length of the form parameter is not the same as that of the actual parameter, the position information of the form parameter and the actual parameter in the source code is output, so that a programmer can be prompted, and the programmer can correct the position information in time to avoid the problem that memory access is out of bounds in the compiling or running process. Compared with a manual checking mode, the method has higher accuracy.

Drawings

In order to more clearly illustrate the embodiments of the present application or the technical solutions in the prior art, the drawings used in the description of the embodiments or the prior art will be briefly described below, it is obvious that the drawings in the following description are only some embodiments of the present application, and for those skilled in the art, other drawings can be obtained according to the drawings without creative efforts.

Fig. 1 is a flowchart of a parameter consistency verification method disclosed in an embodiment of the present application;

FIG. 2 is a schematic diagram of a built data table disclosed in an embodiment of the present application;

fig. 3 is a schematic structural diagram of a parameter consistency verification apparatus disclosed in an embodiment of the present application.

Detailed Description

The parameter consistency verification method disclosed by the embodiment of the application can be carried out before the source code of the program runs, so that the problem of memory access boundary crossing caused by inconsistent memory space occupation of the form parameter and the actual parameter in the running process is avoided.

In the following examples of the present application, a program written in the COBOL language is described as an example. It should be noted that the parameter consistency verification method described in the present application is not limited to the program written in the COBOL language.

The technical solutions in the embodiments of the present application will be clearly and completely described below with reference to the drawings in the embodiments of the present application, and it is obvious that the described embodiments are only a part of the embodiments of the present application, and not all of the embodiments. All other embodiments, which can be derived by a person skilled in the art from the embodiments given herein without making any creative effort, shall fall within the protection scope of the present application.

Fig. 1 is a method for verifying parameter consistency disclosed in an embodiment of the present application, including the following steps:

s101: and acquiring the length information of the form parameter and the actual parameter from the source code of the program written in the COBOL language.

Optionally, besides the length information, other information related to the arguments and the parameters, such as CALL statements, program information, etc., may be obtained.

Specifically, as shown in fig. 2, the following data table is established:

1. PGM Table: the method is used for storing information of a program (hereinafter referred to as COBOL program) in source code written by COBOL language to be analyzed. In fig. 2, PK in the PGM table represents a primary key, id is a unique number assigned to the COBOL program, PGM _ name is the name of the COBOL program, and data _ set is a storage path (optional) of the COBOL program, indicating that the storage path is intended to be distinguished by the storage path if a program with the same name appears.

2. PGM _ ENTRY table: the entry information for storing the COBOL program includes a unique number id assigned to the entry of the COBOL program (it should be noted that, in fig. 2, the id in the different tables only represents the number having the meaning of the table, and not a specific number example, in practice, in order to distinguish different meanings, different types of values and/or letters may be used in the different tables as numbers), a unique number pgm _ id of the COBOL program to which the entry of the COBOL program belongs, here, PGM _ id establishes a correspondence relationship between the PGM _ ENTRY table and the COBOL program in the PGM table (FK 1 in table 2 indicates that other data tables are referred to), a sequence number ENTRY _ seq of an ENTRY of the COBOL program (there may be multiple entries of the COBOL program, where different entries are assigned sequence numbers), a name ENTRY _ name of the ENTRY of the COBOL program, and location information row _ num of the ENTRY of the COBOL program in the source code (specifically, indicates the several rows).

3. E _ PARM _ LIST table: the information of the shape parameters used for storing the entrance of the COBOL program comprises a unique number id allocated to the shape parameters, a unique number ENTRY _ id (corresponding to the PGM _ ENTRY table) of the entrance of the COBOL program to which the shape parameters belong, a sequence number parm _ seq of the shape parameters (possibly a plurality of shape parameters are allocated, sequence numbers are allocated to different shape parameters), a name parm _ name of the shape parameters, and a length parm _ length of the shape parameters.

4. CALL _ STMT table: the information used for depositing the CALL statement in the COBOL program includes: the unique number id assigned to the CALL statement, the unique number PGM _ id of the COBOL program to which the CALL statement belongs (establishing a correspondence relationship with the PGM table), the sequence number CALL _ seq of the CALL statement (there may be multiple CALL statements, where sequence numbers are assigned to different CALL statements), the position information row _ num of the CALL statement in the source code (specifically representing the several rows), the name target of the program called by the CALL statement, the name target _ entry _ name of the entry of the program called by the CALL statement, and the dynamic CALL identifier dyn _ CALL _ flag, which is a first value indicating the presence of a dynamic CALL and a second value indicating the absence of a dynamic CALL.

5. C _ PARM _ LIST table: the method is used for storing the argument information in the CALL statement, and comprises the following steps: the unique number id allocated to the real argument, the unique number called _ id of the CALL statement to which the real argument belongs (establishing a corresponding relationship with the CALL _ STMT table), the sequence number parm _ seq of the real argument, the name parm _ name of the real argument, and the length parm _ length of the real argument.

6. DYN _ CALL _ MAP table: when the CALL statement is a dynamic CALL statement, the target field of the CALL _ STMT table holds the name of the variable, rather than the program name, which is potentially stored in the calledpgm field of the DYN _ CALL _ PGM table. The table is used for maintaining a record mapping relation between a CALL _ STMT table and a DYN _ CALLED _ PGM table, and fields comprise the number CALL _ STMT _ id of a dynamic CALL CALL statement (establishing a corresponding relation with the CALL _ STMT table) and the identifier DYN _ PGM _ id of a program name possibly stored in a dynamic CALL variable (establishing a corresponding relation with the DYN _ CALL _ MAP table).

7. DYN _ CALLED _ PGM table: program information for storing variables of dynamic calls, which may be stored, includes: the number id assigned to the program name that may be stored for the dynamically called variable, the called main program host _ pgm, the variable name var _ name, the location information row _ num of the dynamically called variable in the source code, and the called program name called _ pgm. In this embodiment, multiple dynamic CALL statements are allowed to be associated with the same DYN _ CALL _ PGM table record, and now row _ num holds the location of only one of the CALL statements.

The form is filled in according to the source code, where 6 and 7 are needed in case a dynamic calling method is used in the source code, otherwise no filling is needed. When the CALL statement is a dynamic CALL statement, the target field of the CALL _ STMT table holds the name of a variable, rather than a program name, which the variable may store in the DYN _ CALL _ PGM table, mapped to the CALL statement by the DYN _ CALL _ MAP table.

Specifically, the length of the argument (01-layer or 77-layer variable length) can be determined by defining a PROCEDURE DIVISION header and an ENTRY statement from an argument in the source code. Optionally, when the length of the argument is redefined using the REDEFINE statement in the source code, the maximum one of the initial defined length of the argument determined according to the process resolution header and the ENTRY statement and the length of the argument redefined by the REDEFINE statement is filled in the E _ part _ LIST table as the length of the acquired argument. It should be noted that the Redefine statement is a part of the above-mentioned argument definition or argument definition, and may or may not occur in the middle of the definition.

The length of the argument (01-level or 77-level variable length) can be determined from the program name and the argument used by the CALL statement in the source code. Optionally, when the length of the argument is redefined using the REDEFINE statement in the source code, the maximum one of the initial defined length of the argument determined according to the program name used by the CALL statement and the argument and the length of the REDEFINE argument by the REDEFINE statement is filled in the C _ part _ LIST table as the length of the acquired argument.

For the dynamic CALL case, the variable name of the program name is stored in the CALL statement, and the possible value of the variable name is manually configured through the association table.

S102: and comparing whether the length of the parameters is the same as that of the actual parameters or not and generating a comparison result.

Specifically, the comparison result may be obtained using an "upward analysis method" and/or a "downward analysis method".

The "upward analysis method" refers to looking up the length of the argument of the program to be verified from the table shown in fig. 2, and looking up the call statements calling the argument and the lengths of the arguments in the call statements through the correspondence between the data tables shown in fig. 2. Comparing whether the length of the actual ginseng is the same as that of the physical ginseng.

For the scene that the program to be checked is taken as the callee, the following operations are carried out:

1. all records in PGM _ ENTRY with PGM _ id identical to id of the program under inspection are used as candidate program entries.

2. All records in the CALL _ STMT table, in which the program name pointed by the target is the same as PGM _ name of the program to be checked and the target _ ENTRY _ name is the same as ENTRY _ name of the candidate program ENTRY in the PGM _ ENTRY, are taken as candidate CALL statements.

There are two cases of "program name pointed to by target": one is the value of the target field when it is a non-dynamic call; in another case, when the CALL is dynamically CALLED, the value of the calledjpgm field of the record in the DYN _ CALL _ PGM table needs to be found through the DYN _ CALL _ MAP table. During dynamic calling, multiple programs may correspond to the same CALL statement, and as long as one program matches the CALL statement, the corresponding CALL _ STMT table is recorded as a candidate CALL statement.

3. Matching and checking: and judging whether the parameter lengths of the E _ PARM _ LIST records corresponding to the candidate program entry are consistent with the parameter lengths of the C _ PARM _ LIST records corresponding to the candidate CALL statement.

The "downward analysis method" refers to searching the data table for the length of the real parameter in the call statement of the program, and comparing whether the length of the called parameter of the call statement found by the correspondence between the data tables in fig. 2 is the same as the length of the found real parameter, that is:

for the scenario of the program to be checked as the caller, the following operations are performed:

taking the record with PGM _ id being the same as the id of the program to be checked in each CALL _ STMT as a candidate CALL statement, finding all program names pointed by the target through the candidate CALL statement, further finding the ids of the programs in the PGM, and then finding the record with the id being consistent with the record with the ENTRY _ name being the same as the target _ ENTRY _ name of the candidate CALL statement in the PGM _ ENTRY table as a candidate program ENTRY. Matching checks are performed for these candidate CALL statements and corresponding candidate program entries.

The definition of "program name to which target points" and "content of matching check" is as described above.

If the consistency of the lengths of the form factor and the actual parameter is verified for all the programs in the code, the information of the form factor and the actual parameter of the program to be verified can be filled in the table shown in fig. 2, and one of the upward analysis method and the downward analysis method can be selected according to the information in the table.

If the consistency of the lengths of the form parameter and the actual parameter is verified, an upward analysis method and a downward analysis method are adopted.

S103: and if the comparison result indicates that the length of the parameter is not the same as that of the parameter, outputting the position information of the parameter and the parameter in the source code. If the comparison result indicates that the length of the parameter is the same as that of the parameter, the information that the length of the parameter is consistent with that of the parameter can be output, or no processing is performed.

Specifically, a RESULT table shown in fig. 2 may be generated for storing comparison RESULTs, where PGM _ id represents the number of the checked program (establishing a corresponding relationship with the PGM table), SEQ represents the sequence number assigned for the comparison RESULTs, row _ num represents the location information of the checked specific code statement (which may be referred to as a check point, may be row _ num in the PGM _ ENTRY table, or may be row _ num in the CALL _ STMT table, depending on whether an ENTRY profile of the checked program or an actual argument of the CALL statement is being processed when the RESULT record is generated) in the checked program, and msg represents the comparison RESULTs (the comparison RESULTs are the same or different, and in different cases, the program name to which the corresponding profile or actual argument belongs and the location in the program are also included).

In the process shown in fig. 1, the information of the form parameter and the actual parameter is obtained from the source code, and the result of whether the form parameter length and the actual parameter length are the same is obtained, and under the condition that the form parameter length and the actual parameter length are different, the position information of the form parameter and the actual parameter in the source code is output, so that a programmer can be prompted, and the programmer can correct the position information in time to avoid the problem of memory access out of bounds in the compiling or running process. Compared with a manual checking mode, the method has higher accuracy.

Fig. 3 is a parameter consistency verification apparatus disclosed in an embodiment of the present application, including: the device comprises an acquisition module, a comparison module and an output module.

The obtaining module is used for obtaining the length information of the form parameter and the actual parameter from the program of the source code. The comparison module is used for comparing whether the length of the form parameter is the same as that of the actual parameter and generating a comparison result. And the output module is used for outputting the position information of the parameters and the parameters in the source code if the comparison result indicates that the lengths of the parameters are different from the length of the parameters.

For specific implementation of the functions of the above modules, reference may be made to method embodiments, which are not described herein again.

The device can replace manual investigation and output the position information of the form parameter and the actual parameter with inconsistent lengths in the program, thereby efficiently avoiding the problem of memory access over-bound.

The functions described in the method of the embodiment of the present application, if implemented in the form of software functional units and sold or used as independent products, may be stored in a storage medium readable by a computing device. Based on such understanding, part of the contribution to the prior art of the embodiments of the present application or part of the technical solution may be embodied in the form of a software product stored in a storage medium and including several instructions for causing a computing device (which may be a personal computer, a server, a mobile computing device or a network device) to execute all or part of the steps of the method described in the embodiments of the present application. And the aforementioned storage medium includes: a U-disk, a removable hard disk, a Read-Only Memory (ROM), a Random Access Memory (RAM), a magnetic disk or an optical disk, and other various media capable of storing program codes.

The embodiments are described in a progressive manner, each embodiment focuses on differences from other embodiments, and the same or similar parts among the embodiments are referred to each other.

The previous description of the disclosed embodiments is provided to enable any person skilled in the art to make or use the present application. Various modifications to these embodiments will be readily apparent to those skilled in the art, and the generic principles defined herein may be applied to other embodiments without departing from the spirit or scope of the application. Thus, the present application is not intended to be limited to the embodiments shown herein but is to be accorded the widest scope consistent with the principles and novel features disclosed herein.

Claims

1. A method for verifying parameter consistency, comprising:

storing the length information of the parameters in a preset data table, wherein the data table comprises: an E _ PARM _ LIST table, a C _ PARM _ LIST table, a PGM _ ENTRY table, a CALL _ STMT table and a PGM table;

comparing whether the length of the form parameter is the same as that of the real parameter by using an upward analysis method and/or a downward analysis method, and generating a comparison result; the length of the argument is determined from argument definition progress DIVISION header and ENTRY statement in the source code; the length of the real argument is determined from the CALL statement program name in the source code and the real argument;

the upward analysis method comprises the following steps: taking all records with PGM _ id being the same as id of the program to be checked in the PGM _ ENTRY table as candidate program entries; taking all records in the CALL _ STMT table, wherein the program name pointed by the target is the same as the PGM _ name of the program to be checked, and the target _ ENTRY _ name is the same as the ENTRY _ name of the candidate program ENTRY in the PGM _ ENTRY table, as candidate CALL statements; judging whether the length of the argument recorded by the E _ PARM _ LIST table corresponding to the candidate program entry is consistent with the length of the argument recorded by the C _ PARM _ LIST table corresponding to the candidate CALL statement;

the down analysis method comprises: taking the record with the pgm _ id in each CALL _ STMT table being the same as the id of the program to be checked as the candidate CALL statement; finding all program names pointed by the target through the candidate CALL sentences, and finding program id in the PGM table; finding a record which is consistent with the id and has an ENTRY _ name identical to the target _ ENTRY _ name of the candidate CALL statement according to the PGM _ ENTRY table to serve as a candidate program inlet; judging whether the length of the actual parameter recorded by the C _ PARM _ LIST table corresponding to the candidate program entry is consistent with the parameter length recorded by the E _ PARM _ LIST table corresponding to the candidate CALL statement;

and if the comparison result indicates that the length of the parameter is inconsistent with the length of the parameter, outputting the position information of the parameter and the parameter in the source code.

2. The method of claim 1, wherein the E _ PARM _ LIST table is further configured to:

3. The method of claim 1, wherein the C _ PARM _ LIST table is further configured to:

4. The method of claim 1, wherein the data table further comprises:

the PGM table is used for storing information of the program in the source code; the PGM table comprises a unique number allocated to the program, a name of the program and a storage path of the program;

5. The method of claim 4, wherein the data table further comprises:

a DYN _ CALL _ MAP table and a DYN _ CALLED _ PGM table;

the DYN _ CALLE _ PGM table is used for storing program information which may be stored by a variable of a dynamic call.

6. A parameter consistency verification apparatus, comprising:

the acquisition module is specifically configured to: storing the length information of the parameters in a preset data table, wherein the data table comprises: an E _ PARM _ LIST table, a C _ PARM _ LIST table, a PGM _ ENTRY table, a CALL _ STMT table and a PGM table;

the comparison module is used for comparing whether the length of the form parameter is the same as that of the actual parameter by using an upward analysis method and/or a downward analysis method and generating a comparison result; the length of the argument is determined from argument definition progress DIVISION header and ENTRY statement in the source code; the length of the real argument is determined from the CALL statement program name in the source code and the real argument;

and the output module is used for outputting the position information of the parameters and the parameters in the source code if the comparison result indicates that the lengths of the parameters are not consistent with the length of the parameters.

7. The apparatus of claim 6, wherein the E _ PARM _ LIST table is further configured to:

8. The apparatus of claim 6, wherein the C _ PARM _ LIST table is further configured to:

9. The apparatus of claim 6, wherein the data table further comprises:

10. The apparatus of claim 9, wherein the data table further comprises:

a DYN _ CALL _ MAP table and a DYN _ CALLED _ PGM table;