Data processing: software development – installation – and managem – Software program development tool – Translation of code
Reexamination Certificate
1999-10-12
2002-04-30
Chaki, Kakali (Department: 2122)
Data processing: software development, installation, and managem
Software program development tool
Translation of code
C717S152000, C717S152000, C717S152000, C717S152000, C717S152000
Reexamination Certificate
active
06381736
ABSTRACT:
BACKGROUND OF THE INVENTION
1. Field of the Invention
This invention pertains generally to compile-time error checking. More particularly, the invention is a method for using compile-time function argument checking to validate variables to be substituted into format strings defined in external data files.
2. The Prior Art
In general, routing devices carry out the operation of reliably transferring network messages or packets within a network of coupled devices, or a collection of such networks. A router operating system (ROS) software which is executed by the routing device provides the basic functions for carrying out various router operations. More particularly, a reliable transfer protocol is provided by the ROS for carrying the routing operations. Additionally, a plurality of subsystems are provided in the ROS for carrying out other related routing tasks as is known in the art.
Occasionally during operation, the router may “crash” or otherwise fail to operate. In such case, it is desirable to present to the user of the routing device information in the form of “error messages” for resolving the problem in the “crashed” router device. Such information may include error codes which may be communicated to a technical support technician. The technician can research the error code and better assist the user in resolving the router problem. In addition to error codes, other information which may be provided to the user includes a message text which identifies the particular component of the hardware and/or the particular subsystem within the ROS which is causing the problem. Other explanatory or debugging data may also be provided as part of this process.
Providing error messages to the user is a task carried out by the ROS software executing in the router device. Prior art error message implementations are divided into two types. The first type provides the error message data (error codes, message text, etc.) within the program source code of the ROS software. The second type provides error message data externally from the program source file of the ROS, normally in an error message text file. There are disadvantages to both arrangements as described below.
In the former case, where error message data is provided within the program source file, updates or changes to the error message data are cumbersome or difficult to perform. Because the error message routines and error message data are combined with other router routines within the same ROS program source file, a programmer of the ROS would have to search the program source code for the location of the message routines and message data to make changes and corrections. Furthermore, if a programmer were working with more than one ROS program source file, such as when a programmer is working on several revisions of an ROS file, the programmer would have to make the same changes in each ROS program source file, making global error message data change cumbersome and time consuming.
The main advantage of including the error message data in the ROS program source file is the ability to perform compile-time type-checking of variable format arguments. To display an error message to a user, a function within the ROS is normally called (printf, for example) which accommodates one or more “arguments” or “parameters” associated with the message.
During compilation of the program source file, the compiler provides type-checking of arguments to format specifiers in message-formatting function calls. For example, an illustrative function call may be:
printf (“An error of type %d was generated by %s”, ID, SRC)
In the above example, the call to the function printf includes three arguments, where the first argument is a literal “format string” having the value “An error of type %d was generated by %s”. This “format string” argument is “non-variable” in that its value is fixed in the program source file. In general, this argument value is “hard-coded” and entered into the program source file by the programmer of the program source file. The above format string includes two “format specifiers” (%d and %s), each starting with a “%” symbol followed by an argument type specifier. The remaining arguments (ID and SRC) are “variable”. The format specifiers (%d and %s, in this case) in the format string argument dictate the number and type of arguments to follow in the function call. At compile time, the compiler checks to verify that the ID argument is the proper data-type for the “%d” format specifier and that the SRC argument is the proper data-type for the “%s” format specifier.
Where the data-type for one or more of the arguments is inappropriate for its corresponding format specifier in the format string argument, a compilation error is generated which points out the type-mismatch in the function call. The ROS programmer can then correct the type-mismatch error and recompile the program source file. Such detection of type-mismatch errors is desirable to correct defects in the program source code of the ROS prior to public release of the ROS. If such type-mismatches are not discovered during or prior to compilation, a potential error or malfunction may result during the run-time execution of the ROS of the router.
In the second error message implementation technique, the error message data (error codes, error message text, etc.) is stored in a separate file from the program source file, normally in an “error message text file”. By providing this error message data in an external text file, the message information can be easily accessed and modified by a programmer. Normally, the error message text file organizes the message data in “sectional” format wherein each section applies to a certain component or subsystem of the router, and each section may include one or more messages related to that section. Another benefit associated with externally providing the message data is the ability to use the same error message text file with multiple program source code implementations.
In addition, an external message text file greatly simplifies the process of providing error-messages in multiple languages. For example, where IPV4 error messages are provided in an “IPV4.msg” file, multiple language support could be provided by creating an “IPV4.french.msg” which contains the French translation of the same error messages provided in the “IPV.msg” file.
Error message data are provided to the program source file by calling a function in the program source file which retrieves the pertinent error message data, such as:
IP_bad_route_format=get format (IP_bad_route);
During router operation, the above command retrieves the message text associated with a bad route from the error message text file and stores the message into the variable “IP_bad_route_format”. The variable “IP_bad_route_format” contains the functional equivalent value of the “literal string” argument as in the first error message implementation, but obtains its value at “run-time” during router execution. The variable “IP_bad_route_format” is used in conjunction with the output function (printf) to display the error message to the user. For example, the printing call might be:
printf (IP_bad_route_format, ID, SRC)
The error message is then displayed to the user for troubleshooting the problem associated with the present error. However, since the IP_bad_route_format value is defined at run-time, during compilation of the program source file, the value of the IP_bad_route_format variable is unknown. Unlike the first error message implementation where the message text is “hard-coded” with the output function printf, the content of the message text and thus the format specifiers within the message text provided by the IP_bad_route_format variable is unknown to the compiler. Accordingly, the compiler will not perform type-checking of such function call statements (i.e., the compiler will not check whether the ID and SRC arguments match the data-type specified by the format specifiers in the IP_bad_route_format variable). Because the compiler does not perform type-checking with respect to this se
Hiller Dean
Klotz Frank
Kluft Ian
May, Jr. William B.
Chavis John Q.
Cisco Technology Inc.
Sierra Patent Group Ltd.
LandOfFree
Method for compile-time type-checking of arguments for... does not yet have a rating. At this time, there are no reviews or comments for this patent.
If you have personal experience with Method for compile-time type-checking of arguments for..., we encourage you to share that experience with our LandOfFree.com community. Your opinion is very important and Method for compile-time type-checking of arguments for... will most certainly appreciate the feedback.
Profile ID: LFUS-PAI-O-2902607