System and method for preventing software errors

FIELD OF THE INVENTION

0001The present disclosure relates to systems and methods for executing computer programs. More particularly, the disclosure relates to systems and methods for preventing software errors that are caused by address range or alignment errors without adding range and alignment information to the run-time-architecture of each procedure call.

BACKGROUND OF THE INVENTION

0002In general, there are only two forms of a data object in a program, instances and references. An instance is the actual data object, and can be created statically by the compiler or dynamically by the application. A reference occurs when a function accesses a data object whose instance was created elsewhere (usually in another function).

0003Ordinarily, all programs are comprised of one or more functions. Larger programs may have the sources for many of the functions stored in separate files for convenience of maintenance and to reduce compile time. Since the source for these large programs are stored in separate files, they are compiled into relocatable object files (i.e., “.” files) that have one-to-one correspondence with their source file. The compilation of these source files into the relocatable object files has a temporal nature. A relocatable object file derived from one source can be produced one month and a relocatable object file derived from another source file can be produced in another month. A resulting program can then be constructed by linking two relocatable object files at a third time without compromising the correctness of the program. This linking without compromising the correctness of the program is provided on the condition that none of the source files are changed between the compilation of the first source file and the compilation of the second source file.

0004This utilization of the relocatable object file derived from one source that can be produced in one month and accessed and re-utilized in other modules at a later time normally will not have address range or alignment errors caught by the linker. This is especially true during the development of the multiple code modules, in that the program can then have a high failure rate during execution. Therefore, there is a need for the developers to have the ability to have address range or alignment check performed at run-time to ensure run-time program correctness. This address range or alignment checking is needed because of inconsistent references to objects that change over time.

0005There is also a great need to make this address range or alignment check temporary, because once the developers have ensured the run-time correctness of the program then the additional overhead caused in space or time to perform this run-time checking need not be performed on an ongoing basis when the program is in normal production or is being utilized by the end user.

0006There is also the need to have the run-time address range or alignment checking performed on an as needed basis (i.e. switchable) should errors occur during normal operation. This switchable run-time checking would then allow for the debugging of the program modules at a later time by switching the run-time checking to an “on” mode to assist in debugging of the programs. In order to have this switchable, there is a need to allocate the space required for a methodology to perform the run-time address range or alignment checking at any time desired.

0007However, if one of the relocatable object files is produced from a first source, and a data object declaration in a second source that is used by both of the source files is changed in the common header file, a second relocatable object file is produced from the second source file. Then the two relocatable object files will contain data object declarations that are incompatible, but not detectably different.

0008From the foregoing, it can be appreciated that it would be desirable to have a system and method for preventing software errors caused by address range or alignment errors.

SUMMARY OF THE INVENTION

0009The present disclosure relates to system and method for preventing software errors that are caused by address range or alignment errors. Briefly described, in architecture, a preferred embodiment of the system includes a compiler that parses a program. The compiler further comprises a logic that generates a verification value for a block of code in the program, a logic that stores the verification value in the block of code, and a logic that inserts verification value instruction code into the block of code.

0010The present invention can also be viewed as providing a method for preventing software errors that are caused by address range or alignment errors. In this regard, the preferred method can be broadly summarized by the following steps: (1) generating a verification value for a block of code in the program; (2) storing the verification value in the block of code; (3) computing a runtime verification value for the block of code during execution of the program; (4) executing the block of code if the verification value equals the runtime verification value; and (5) generating an error message if the verification value does not equals the runtime verification value.

0011Other systems, methods, features, and advantages of the present invention will be or become apparent to one with skill in the art upon examination of the following drawings and detailed description. It is intended that all such additional systems, methods, features, and advantages be included within this description, be within the scope of the present invention, and be protected by the accompanying claims.

BRIEF DESCRIPTION OF THE DRAWINGS

The invention can be better understood with reference to the following drawings. The components in the drawings are not necessarily to scale, emphasis instead being placed upon clearly illustrating the principles of the present invention. Moreover, in the drawings, like reference numerals designate corresponding parts throughout the several views.

<figref idref="DRAWINGS">FIG. 1</figref> is a block diagram of a user system showing the compiler with the hash value code generation, source program code and executable code within a memory area.

<figref idref="DRAWINGS">FIG. 2</figref> is a block diagram illustrating an example of the process flow used to create an executable program that includes the hash value mechanism of the present invention.

<figref idref="DRAWINGS">FIG. 3</figref> is a flow chart illustrating functionality of an example of the compilation process utilizing the hash value code generation mechanism of the present invention, as shown in <figref idref="DRAWINGS">FIG. 1</figref>.

<figref idref="DRAWINGS">FIG. 4</figref> is a flow chart illustrating preferred functionality of an example of the parser utilized by the compilation process, as shown in <figref idref="DRAWINGS">FIG. 3</figref>.

<figref idref="DRAWINGS">FIG. 5</figref> is a flow chart illustrating preferred functionality of the hash value code generation process of the present invention, as shown in <figref idref="DRAWINGS">FIGS. 1</figref>, <b>2</b> and <b>3</b>.

<figref idref="DRAWINGS">FIG. 6</figref> is a flow chart illustrating preferred functionality of an example of the executable code process that operates the hash value code generated by the hash value code generation process, as shown in <figref idref="DRAWINGS">FIG. 5</figref>.

<figref idref="DRAWINGS">FIG. 7</figref> is a block diagram illustrating an example of an address range and alignment error to be detected by the present invention.

<figref idref="DRAWINGS">FIG. 8A</figref> is a block diagram illustrating an example of a simple object structure with the generated hash value generated by the hash value code generation process of the present invention, as shown in <figref idref="DRAWINGS">FIGS. 1–3</figref> and <b>4</b>.

<figref idref="DRAWINGS">FIG. 8B</figref> is a block diagram illustrating an example of a complex object structure with the generated hash value generated by the hash value code generation process of the present invention, as shown in <figref idref="DRAWINGS">FIGS. 1–3</figref> and <b>4</b>.

DETAILED DESCRIPTION

0022Referring now in more detail to the drawings, in which like numerals indicate corresponding parts throughout the several views, the present invention will be described. While the invention is described in connection with these drawings, there is no intent to limit it to the embodiment or embodiments disclosed therein. On the contrary, the intent is to cover all alternatives, modifications, and equivalents included within the spirit and scope of the invention as defined by the appended claims.

0023The present invention relates to systems and methods for preventing software errors caused by address range and alignment errors. The present invention augments the compiler to add information about the instance of an object that uniquely identifies the name, size, type, or order of the elements that make up the object. This information about the instance of an object can be called a verification value, hash value or signature, and will be hereafter referred to as a hash value. This hash value is placed immediately before each object (i.e., in memory and has a lower address than the base address of the object). This is optionally done by the compiler when it allocates the object statically.

0024As stated previously, the hash value is a generated digital signature for an object. This digital signature can be generated from the object name, object size, object order, or object type for a simple object structure. In addition, for the complex object structure, the order of simple objects within the complex object structure may also be used to compute the verification value, hash value or digital signature. In this regard, it is possible for the verification value, hash value or digital signature to indicate if simple or complex objects within a complex object have been re-ordered from a previously defined layout. In this situation, the size and data range will be consistent, however, the alignment of each of the objects within a complex object may be off considerably from the previously defined object.

0025When an application creates an object by calling a memory-allocation function (i.e. dynamic), special handling typically is needed because the allocation function is usually typeless. Typeless means it allocates space but it does not know what object will be placed within the space. Through programming conventions, the program developer creates a new allocation function for each type of object that is dynamically created. This function allocates the space for the object and space for the hash value. It initializes the hash value, then returns a pointer to the space allocated for the object. Extensions to the language via pragmas can make this step of the allocation and initialization transparent to the program developer.

0026References to the object are passed from function to function by passing a “pointer” to the base (i.e. lowest) address of the object. This address is not a pointer to the hash value of the object. The compiler is augmented in at least some embodiments of this invention so that the compiler checks for the presence of the hash value stored in memory immediately before (i.e. lower address) the base address of the object. If the hash value is present, codes inserted in the function by the compiler compares the hash value of the external object against a hash value the compiler has computed for the object when the function was compiled. If the hash values match, the function proceeds. If the hash values do not match, an irrecoverable failure path can be executed.

0027By computing hash values when objects are created, and computing and comparing hash values when objects are referenced, any change made to the object that happened between compiling one source module and compiling a second source module is detectable by the application at run-time. Typically, compiler type checking only detects errors of code references at the time each module is compiled. It cannot detect errors caused because of changes made to the object declaration between compiles.

0028The present invention comprises a system and method for preventing software errors caused by address range and alignment errors. This is particularly important when you have multiple programmers developing a system where there are multiple modules created by separate groups of programmers. When this type of system generation is utilized, there is a higher incidence of errors due to miscommunication of object reference definitions. This is particularly important in some computer programs that share object references that are created and modified by different programmers for their particular modules over time. Therefore, the data object is not consistent across all modules. This can create a tremendous problem in that many computer languages during compilation and linking will not catch the address range or alignment errors, and therefore the errors will only occur at run-time. An example of one method to establish whether or not a hash value is generated is the allocation of a flag or unique identifier (e.g., a magic number to indicate that a hash value is available for this object).

0029Turning now to the drawings, <figref idref="DRAWINGS">FIG. 1</figref> is a block diagram example of a general-purpose computer that can implement the hash value code generation mechanism of the invention. Generally, in terms of hardware architecture, as shown in <figref idref="DRAWINGS">FIG. 1</figref>, the computer <b>5</b> includes a processor <b>11</b>, memory <b>12</b>, and one or more input devices and/or output (I/O) devices <b>15</b> (or peripherals) that are communicatively coupled via a local interface <b>13</b>. The local interface <b>13</b> can be, for example but not limited to, one or more buses or other wired or wireless connections, as is known in the art. The local interface <b>13</b> may have additional elements, which are omitted for simplicity, such as controllers, buffers (caches), drivers, repeaters, and receivers, to enable communications. Further, the local interface <b>13</b> may include address, control, and/or data connections to enable appropriate communications among the aforementioned components.

0030The processor <b>11</b> is a hardware device for executing software that can be stored in memory <b>12</b>. The processor <b>11</b> can be virtually any custom made or commercially available processor, a central processing unit (CPU) or an auxiliary processor among several processors associated with the computer <b>5</b>, and a semiconductor based microprocessor (in the form of a microchip) or a macroprocessor. Examples of suitable commercially available microprocessors are as follows: an 80×86, Pentium or Itanium series microprocessor from Intel Corporation, U.S.A., a PowerPC microprocessor from IBM, U.S.A., a Sparc microprocessor from Sun Microsystems, Inc, a PA-RISC series microprocessor from Hewlett-Packard Company, U.S.A., or a 68xxx series microprocessor from Motorola Corporation, U.S.A.

0031The memory <b>12</b> can include any one or combination of volatile memory elements (e.g., random access memory (RAM, such as DRAM, SRAM, etc.)) and nonvolatile memory elements (e.g., ROM, hard drive, tape, CDROM, etc.). Moreover, the memory <b>12</b> may incorporate electronic, magnetic, optical, and/or other types of storage media. Note that the memory <b>12</b> can have a distributed architecture, where various components are situated remote from one another, but can be accessed by the processor <b>11</b>.

0032The software in memory <b>12</b> may include one or more separate programs, each of which comprises an ordered listing of executable instructions for implementing logical functions. In the example of <figref idref="DRAWINGS">FIG. 1</figref>, the software in the memory <b>12</b> includes an operating system <b>19</b>, a source program code <b>30</b> that includes source function code <b>31</b> and source allocation code <b>32</b>, the hash value code generation mechanism <b>100</b> in the compiler <b>40</b>, and executable code <b>120</b> that includes hash value code <b>130</b>.

0033A non-exhaustive list of examples of suitable commercially available operating systems <b>19</b> is as follows: a Windows operating system from Microsoft Corporation, U.S.A., a Netware operating system available from Novell, Inc., U.S.A., an operating system available from IBM, Inc., U.S.A., any LINUX operating system available from many vendors or a UNIX operating system, which is available for purchase from many vendors, such as Hewlett-Packard Company, U.S.A., Sun Microsystems, Inc. and AT&amp;T Corporation, U.S.A. The operating system <b>19</b> essentially controls the execution of other computer programs, such as the hash value code operation mechanism, and provides scheduling, input-output control, file and data management, memory management, and communication control and related services.

0034The hash value code generation mechanism <b>100</b> and the compiler <b>40</b> may be a source program, executable program (object code), script, or any other entity comprising a set of instructions to be performed. When a source program, then the program is usually translated via a compiler, assembler, interpreter, or the like, which may or may not be included within the memory <b>12</b>, so as to operate properly in connection with the O/S <b>19</b>. Furthermore, the hash value code generation mechanism <b>100</b> and the compiler <b>40</b> can be written as (a) an object oriented programming language, which has classes of data and methods, or (b) a procedure programming language, which has routines, subroutines, and/or functions, for example but not limited to, C, C++, Pascal, BASIC, FORTRAN, COBOL, Perl, Java, and Ada.

0035The I/O devices <b>15</b> may include input devices, for example but not limited to, a keyboard, mouse, scanner, microphone, etc. Furthermore, the I/O devices <b>15</b> may also include output devices, for example but not limited to, a printer, display, etc. Finally, the I/O devices <b>15</b> may further include devices that communicate both inputs and outputs, for instance but not limited to, a modulator/demodulator (modem; for accessing another device, system, or network), a radio frequency (RF) or other transceiver, a telephonic interface, a bridge, a router, etc.

0036If the computer <b>5</b> is a PC, workstation, or the like, the software in the memory <b>12</b> may further include a basic input output system (BIOS) (omitted for simplicity). The BIOS is a set of essential software routines that initialize and test hardware at startup, start the O/S <b>19</b>, and support the transfer of data among the hardware devices. The BIOS is stored in ROM so that the BIOS can be executed when the computer <b>5</b> is activated.

0037When the computer <b>5</b> is in operation, the processor <b>11</b> is configured to execute software stored within the memory <b>12</b>, to communicate data to and from the memory <b>12</b>, and to generally control operations of the computer <b>5</b> pursuant to the software. The hash value code generation mechanism <b>100</b> in the compiler <b>40</b> and the O/S <b>19</b> are read, in whole or in part, by the processor <b>11</b>, perhaps buffered within the processor <b>11</b>, and then executed.

0038When the hash value code generation mechanism <b>100</b> in the compiler <b>40</b> is implemented in software, as is shown in <figref idref="DRAWINGS">FIG. 1</figref>, it should be noted that the mechanism <b>100</b> and the compiler <b>40</b> can be stored on virtually any computer readable medium for use by or in connection with any computer related system or method. In the context of this document, a computer readable medium is an electronic, magnetic, optical, or other physical device or means that can contain or store a computer program for use by or in connection with a computer related system or method. The hash value code generation mechanism <b>100</b> and the compiler <b>40</b> can be embodied in any computer-readable medium for use by or in connection with an instruction execution system, apparatus, or device, such as a computer-based system, processor-containing system, or other system that can fetch the instructions from the instruction execution system, apparatus, or device and execute the instructions.

0039In the context of this document, a “computer-readable medium” can be any means that can store, communicate, propagate, or transport the program for use by or in connection with the instruction execution system, apparatus, or device. The computer readable medium can be, for example but not limited to, an electronic, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, device, or propagation medium. More specific examples (a nonexhaustive list) of the computer-readable medium would include the following: an electrical connection (electronic) having one or more wires, a portable computer diskette (magnetic), a random access memory (RAM) (electronic), a read-only memory (ROM) (electronic), an erasable programmable read-only memory (EPROM, EEPROM, or Flash memory) (electronic), an optical fiber (optical), and a portable compact disc read-only memory (CDROM) (optical). Note that the computer-readable medium could even be paper or another suitable medium upon which the program is printed, as the program can be electronically captured, via for instance optical scanning of the paper or other medium, then compiled, interpreted or otherwise processed in a suitable manner if necessary, and then stored in a computer memory.

0040In an alternative embodiment, where hash value code generation mechanism <b>100</b> and the compiler <b>40</b> are implemented in hardware, the hash value code generation mechanism <b>100</b> can be implemented with any one or a combination of the following technologies, which are each well known in the art: a discrete logic circuit(s) having logic gates for implementing logic functions upon data signals, an application specific integrated circuit (ASIC) having appropriate combinational logic gates, a programmable gate array(s) (PGA), a field programmable gate array (FPGA), etc.

0041Illustrated in <figref idref="DRAWINGS">FIG. 2</figref> is a block diagram illustrating an example of the process to create and execute a program with the hash value code generation mechanism <b>100</b>. First, the source program code <b>30</b> containing the source function code <b>31</b> and source allocation code <b>32</b> is input into the program compiler <b>40</b>. The program compiler <b>40</b> containing the hash value code generation mechanism <b>100</b> generates a nonexecutable object program <b>51</b> that includes hash value code. The nonexecutable object program <b>51</b>, including the hash value code, is then processed by the base linking program <b>61</b>. The base linking program <b>61</b> generates an executable code <b>120</b> that includes the hash value code <b>130</b>. During execution of the executable code <b>120</b>, including the hash value code <b>130</b>, objects <b>140</b> are created. These objects <b>140</b> are utilized in the operation of the executable code <b>120</b>. Some objects <b>140</b> are created with a hash value defined using hash value code <b>130</b>.

0042Illustrated in <figref idref="DRAWINGS">FIG. 3</figref> is a flow chart depicting functionality of an example of the compilation process <b>40</b>, including the hash value code generation mechanism <b>100</b> of the present invention. First, the compilation process <b>40</b> is initialized at step <b>41</b>. At step <b>42</b>, a lexical analyzer is performed on source code <b>30</b> (<figref idref="DRAWINGS">FIG. 2</figref>). At step <b>43</b>, a parser is executed. The parser functionality is herein described in further detail with regard to <figref idref="DRAWINGS">FIG. 4</figref>.

0043At step <b>44</b>, the semantic analyzer is operated and the register allocation is performed at step <b>45</b>. At step <b>46</b>, the code generation process is executed. The code generation process generates the nonexecutable object program <b>45</b>. At step <b>47</b>, the compilation process <b>40</b> then executes the hash value code generation mechanism that inserts hash value code into the nonexecutable object program <b>45</b>. The hash value code generation mechanism is herein described in further detail with regard to <figref idref="DRAWINGS">FIG. 5</figref>.

0044Next, the final assembly of the nonexecutable object program <b>51</b> is performed (step <b>48</b>). This final assembly of the nonexecutable object program includes the hash value code generated at step <b>47</b>. At step <b>49</b>, the compilation process <b>40</b> then exits.

0045Illustrated in <figref idref="DRAWINGS">FIG. 4</figref> is a flow chart illustrating functionality of an example of the parser <b>80</b> that is within the compiler <b>40</b> that utilizes the hash value code generation mechanism <b>100</b> of the present invention. The parser <b>80</b> parses each of the statements within the source code <b>30</b> and allocates space for objects and hash values generated then and inserts code into a block to test the hash value if it is indicated that a hash value is to be generated for a particular object.

0046First, the parser is initialized and gets the first data statement at step <b>81</b>. At step <b>82</b>, the parser <b>80</b> then analyzes the code statement. At step <b>83</b>, the parser <b>80</b> then determines whether the statement is an assignment statement.

0047If at step <b>83</b>, the parser <b>80</b> determines that the statement analyzed is not an assignment statement, then the parser <b>80</b> determines whether the statement analyzed (step <b>82</b>) is a data statement at step <b>84</b>. If it is determined at step <b>84</b> that the analyzed statement is not a data statement, then the parser <b>80</b> proceeds to step <b>94</b>. However, if it is determined at step <b>84</b> that the statement analyzed at step <b>82</b> is a data statement, then the parser <b>80</b> checks whether a hash value generation is needed at step <b>85</b>.

0048The indication by the programmer that a hash value needs to be generated for this data statement is generally performed in pre-described manners defined by the particular program language used for the identified program code. For example, when utilizing the C program language for program generation, the developer, i.e., the programmer, can utilize pragma statements or predetermined configured flags to indicate to the compiler whether or not a hash value is to be generated for this particular data statement. It is contemplated by the inventor that hash value generation can be turned on for some data statements in the program and turned off for others therefore specifically targeting which data statements require the hash value generation. This enables the programmer to have complete control over what data statements are tested. This enables the developer to identify which data statements are more at risk for run-time errors due to invalid type referencing. It is also contemplated by the inventor that this form of specified or focused type checking can be utilized in the assembler by assembly programs using end line assembler directives.

0049If it is determined at step <b>85</b> that a hash value is not needed, then the parser <b>80</b> then proceeds to step <b>94</b>. However, if it is determined at step <b>85</b> that the data statement does need a hash value, then the parser <b>80</b> determines whether space is allocated for the generated hash value at step <b>86</b>. If it is determined at step <b>86</b> that the space is allocated, then the parser <b>80</b> proceeds to step <b>88</b>. However, if it is determined at step <b>86</b> that the space for the needed hash value is not allocated, then the parser <b>80</b> allocates the space for the object and hash value at step <b>87</b>.

0050At step <b>88</b>, the parser <b>80</b> then computes the hash value and inserts the hash value code into the code block and then proceeds to step <b>94</b>. As stated previously, this hash value or digital signature is computed on at least one of a variety of different elements within the object. The elements include the object name, the object size, the order of objects within the current object just to name a few elements. However, the inventors realize that a number of different elements within the object can be used to compute a unique hash value that indicates the structure of the current object.

0051However, if it is determined at step <b>83</b> that the statement parsed is an assignment statement, the parser <b>80</b> then proceeds to step <b>91</b>. At step <b>91</b>, the parser <b>80</b> determines whether the statement references an external object. If it is determined at step <b>91</b> that the statement does not reference an external object, then the parser <b>80</b> proceeds to step <b>94</b> to process other code generation. However, if it is determined at step <b>91</b> that the statement referenced is an external object, the parser <b>80</b> then determines whether the external object has a hash value at step <b>92</b>. If it is determined at step <b>92</b> that the object is not to have a hash value, the parser <b>80</b> then proceeds to step <b>94</b> to process other code generation. However, if it is determined at step <b>92</b> that the object has a hash value, then the parser <b>80</b> inserts the code in the code block to test the generated hash value, at step <b>93</b>.

0052At step <b>94</b>, the parser then processes other code generation as known in the art, and then determines if there are more statements to be processed (step <b>95</b>). If there are more statements to be processed, then the parser <b>80</b> gets the next statement at step <b>96</b> and returns to repeat steps <b>82</b>–<b>95</b>. However, if it is determined at step <b>95</b> that there are no more statements to be processed, then the parser <b>80</b> exits at step <b>99</b>.

0053Illustrated in <figref idref="DRAWINGS">FIG. 5</figref> is a flow chart depicting functionality of an example of the check code generation mechanism <b>100</b> of the present invention that is utilized by the compiler <b>40</b> (<figref idref="DRAWINGS">FIG. 3</figref>). First, the hash value code generation mechanism <b>100</b> is initialized at step <b>101</b>. At step <b>102</b>, the hash value code generation mechanism <b>100</b> then finds the first or next statically allocated object procedure call or function call.

0054At step <b>103</b>, the hash value code generation mechanism <b>100</b> determines whether the next allocated object procedure call or function call is indeed a procedure or function call. If it is determined at step <b>103</b> that the next statically allocated block is a procedure or function call, then the hash value code generation mechanism <b>100</b> then identifies the base address, object size, number of elements, and type and order of elements in the procedure or function call, at step <b>104</b>. At step <b>105</b>, the hash value is stored for the procedure or function call in the content declaration for the procedure or function call. The hash value for the procedure or function call is also stored in the function or procedure calling code. Next, the hash value code generation mechanism <b>100</b> proceeds to step <b>108</b> to see whether there are more hash values to be generated.

0055However, if it is determined at step <b>103</b> that the next statically allocated object procedure call or function call is not a procedure or function call, then the hash value code generation mechanism <b>100</b> analyzes the statically allocated object and generates a hash value based upon the number of elements and type and order of elements in the statically allocated object, at step <b>106</b>. At step <b>107</b>, the hash value is stored for the statically allocated object in the object declaration.

0056At step <b>108</b>, the hash value code generation mechanism determines whether there is more hash value code to be generated for statically allocated object, procedure or function calls. If it is determined at step <b>108</b> that there are more statically allocated object, procedure or function calls, then the hash value code generation mechanism <b>100</b> returns to repeat steps <b>102</b> through <b>108</b>. However, if it is determined at step <b>108</b> that there are no more statically allocated object, procedure or function calls for hash values to be generated, then the hash value code generation mechanism <b>100</b> exits at step <b>109</b>.

0057Illustrated in <figref idref="DRAWINGS">FIG. 6</figref> is a flow chart depicting functionality of an example of the executable code process <b>120</b> that includes the hash value code <b>130</b> generated by the hash value code generation mechanism <b>100</b> of the present invention. First, the executable code process <b>120</b> is initialized at step <b>121</b>. At step <b>122</b>, the executable code process is run. At step <b>123</b>, the executable code process <b>120</b> determines whether the executed statement is a statically allocated object, procedure or function call. If it is determined at step <b>123</b> that the next statement is not a statically allocated object, procedure or function call, then the executable code process <b>120</b> returns to repeat steps <b>122</b> and <b>123</b>.

0058However, if it is determined at step <b>123</b> that the next code executed is a statically allocated object, procedure or function call, then at step <b>131</b>, the executable code process <b>120</b> runs the hash value code <b>130</b> that determines whether there is hash value space allocated for the statically allocated object, procedure or function call. If it is determined at step <b>131</b> that there is hash value space allocated for the statically allocated object, procedure or function call, then the hash value code <b>130</b> verifies the hash value in the statically allocated object, procedure or function call to make sure that it matches the size of each object and the number of elements in the array for the generated hash value at step <b>132</b>. The hash value code <b>130</b> then proceeds to identify whether the hash value in the statically allocated object, procedure or function call matches the hash value in the array at step <b>133</b>. At step <b>133</b>, the hash value code <b>130</b> determines whether the hash values match. If it is determined at step <b>133</b> that the hash values do not match, then the hash value code <b>130</b> generates an error message of hash value mismatch at step <b>133</b> and then exits at step <b>129</b>. However, if the hash value code <b>130</b> determines at step <b>133</b> that the hash values do match, then the executable code process <b>120</b> resumes processing.

0059The executable code process <b>120</b> then determines whether it is done processing code statements at step <b>125</b>. If it is determined at step <b>125</b> that there are more code statements to be processed, then the executable code process <b>120</b> returns to repeat steps <b>122</b> through <b>125</b>. However, if it is determined at step <b>125</b> that there is no more executable code to be run, then the executable code process <b>120</b> exits at step <b>129</b>.

0060Illustrated in <figref idref="DRAWINGS">FIG. 7</figref> is a block diagram illustrating an example of an address range and alignment error to be detected by the present invention. As shown, object <b>141</b> contains objects <b>142</b>A, B and C and object <b>145</b> contains objects <b>146</b>A, B and C. As shown, object <b>142</b>A is of size and range Y where object N <b>146</b>A is of size X where X does not equal Y. This is to illustrate that if a first program is compiled with a definition of object <b>141</b> to contain objects <b>142</b>A through <b>142</b>C of a particular size and a second program refers to objects <b>145</b> consisting of objects <b>146</b>A through <b>146</b>C and that these are to be identical objects then it can be seen that references to object <b>145</b> which is defined as object <b>141</b> would cause a range and alignment error.

0061Illustrated in <figref idref="DRAWINGS">FIG. 8A</figref> is a block diagram illustrating an example of a simple object structure <b>150</b> with the generated hash value <b>152</b> generated by the hash value code generation process of the present invention, as shown in <figref idref="DRAWINGS">FIGS. 1–3</figref> and <b>4</b>. As illustrated, the simple object structure <b>150</b> comprises a simple object value <b>153</b>. In addition, with implementation of the hash value code generation process of the present invention, at least the hash value <b>152</b> is included with the definition of the simple object value <b>153</b>. In addition, <figref idref="DRAWINGS">FIG. 8A</figref> also illustrates a magic number <b>151</b> to indicate the operation of the hash value for verification of address range and alignment in addition to the size of the simple object <b>155</b>. These fields, in addition to the simple object value <b>153</b> construct the simple object structure <b>150</b> of the present invention.

0062Illustrated in <figref idref="DRAWINGS">FIG. 8B</figref> is a block diagram illustrating an example of a complex object structure <b>160</b> with the generated hash value <b>162</b> generated by the hash value code generation process of the present invention, as shown in <figref idref="DRAWINGS">FIGS. 1–3</figref> and <b>4</b>. As shown, a complex object structure <b>160</b> can comprise many different simple object structures <b>150</b> or other complex object structures <b>160</b> within the structure. The complex object structure <b>160</b> comprises at least two or more simple object structures <b>150</b> and in most cases comprises, as in the definition of an array, numerous simple object structures <b>150</b>.

0063As shown in <figref idref="DRAWINGS">FIG. 8B</figref>, the illustrated example complex object structure <b>160</b> contains simple object structure A<b>150</b>A and simple object structure B <b>150</b>B, as each one of the simple object structures <b>150</b> are previously defined with regard to <figref idref="DRAWINGS">FIG. 8A</figref> and each contain their own hash value <b>152</b>A and <b>152</b>B. The complex object structure <b>160</b> then utilizes these hash values from the simple object structure <b>150</b>A and <b>150</b>B to generate a complex object hash value <b>162</b>. This complex object hash value <b>162</b> can indicate the object name, object size and object type and order of any of the simple or complex object structures within it. The complex object structure <b>160</b> also may contain the complex object magic number <b>161</b> to indicate whether or not the hash value capability is available for the current complex object structure <b>160</b>. It is also contemplated by the inventor that the complex object magic number <b>161</b> can indicate whether or not the capability is currently switched on for utilization of the complex object hash value <b>162</b>. In addition, it is contemplated by the inventors that the complex object structure <b>160</b> can contain indicators of the size of the complex object <b>165</b> in addition to the indicator of the number of elements in the complex object <b>164</b>. Utilization of these indicators can further insure address range and alignment errors are detected at run-time.

0064While particular embodiments of the invention have been disclosed in detail in the foregoing description and drawings for purposes of example, it will be understood by those skilled in the art that variations and modifications thereof can be made without departing from the scope of the invention as set forth in the following claims.