CA2170939A1 - Method and apparatus for displaying locations of errors detected inside software macro calls - Google Patents

Method and apparatus for displaying locations of errors detected inside software macro calls

Info

Publication number
CA2170939A1
CA2170939A1 CA002170939A CA2170939A CA2170939A1 CA 2170939 A1 CA2170939 A1 CA 2170939A1 CA 002170939 A CA002170939 A CA 002170939A CA 2170939 A CA2170939 A CA 2170939A CA 2170939 A1 CA2170939 A1 CA 2170939A1
Authority
CA
Canada
Prior art keywords
macro
error
source program
source
location
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Abandoned
Application number
CA002170939A
Other languages
French (fr)
Inventor
Leonid M. Arbouzov
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Sun Microsystems Inc
Original Assignee
Leonid M. Arbouzov
Sun Microsystems, Inc.
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Leonid M. Arbouzov, Sun Microsystems, Inc. filed Critical Leonid M. Arbouzov
Publication of CA2170939A1 publication Critical patent/CA2170939A1/en
Abandoned legal-status Critical Current

Links

Classifications

    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F8/00Arrangements for software engineering
    • G06F8/40Transformation of program code
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F8/00Arrangements for software engineering
    • G06F8/40Transformation of program code
    • G06F8/41Compilation
    • G06F8/42Syntactic analysis
    • G06F8/423Preprocessors
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F8/00Arrangements for software engineering
    • G06F8/40Transformation of program code
    • G06F8/41Compilation
    • G06F8/42Syntactic analysis
    • G06F8/425Lexical analysis

Abstract

A method and apparatus for generating more helpful error messages during compilation of a software program. The software program contains a macro definition and an invocation of the macro.
The macro is expanded during the compilation process. The invention generates several tables that save the history of the macro expansion. If an error occurs during compilation of the macro, the invention prints an error message, using the saved history information, that specifically identifies the location of the error in the source program of the macro and the history of the macro expansion. The invention can print multi-line macro histories for nested macro calls.

Description

` 2170~3g ~THOD AND APPARATUS FOR DISPLAYING LOCATIO~S OF
ERRORS DETECTED INSIDE SOFTWARE ~CRO CALLS

BACKGROUNO OF THE INVENT~ON

This invention relates to a method and apparatus for compiling a software program and, more particularly, to a s~tem and method for providing accurate information concerning errors detected during 5 compilation of a software program.
Certain co~ ter l~n~ es, such as the C co~ ter l~n~ ge, are called "high level languages." High level languages allow a programmer to write a computer program in a forrn that is easily read and understood by human beings. Such a computer program is called a 0 "sou,rce program." The source program is input to another computer program called a "compiler," which converts the source program to an "object program." An object program has a format that is easily understood and executed by a computer. During compilation, the compiler breaks the components of the source program into "tokens,"
which are then further processed by the compiler to yield the object program.
Conventional compilers often produce a printed report detailing the status of the compilation process. Such a report in~hldes error m~ss~ges listing errors discovered in the source program during 2 o compilation. An example of an error in a source program that might cause an error m~cs~ge would be the use of an "undefined symbol" in the source program.
Certain high level l~n~ es~ such as the C progr~mminp l~n~l~ee, in~l~lde progr~mming constructs called "macros." Macros 2 5 generally contain a portion of a computer program that is used in more than one place in the source program. The contents of a macro are specified in a "macro definition" within the source prograrn. During 2170~39 compilation, a macro is inserted into the source program at a point in the source program cont~inine a "macro call" for that macro. The process of inserting a macro into the source program at the location of a macro call is called "macro e~r~ncion." In most high level l~n~lagesJ
a macro call to a second macro can be "nested" inside a macro ~efinitio~ of a first macro to produce a "nested macro call.n -When an error occurs during compilation of a source program cont~ining a macro call, collvenlional compilers do not produce helpful error messages. Conventional compilers identify only the line number 0 of the macro call, but do not identify the line number within the macro where the compilation error actually occurred. Moreover, convelltional compilers do not print error messages showing a history of macro expansion. Conventional compilers are especially unhelpful when the compiler is compiling nested macro calls. Even though a nested macro call might expand to multiple lines of source program, a conventional compiler will only identify the line number in the source program of the original macro call. What is needed is a compiler that prints error mecs~ees that more specifically identify a location of an error during compilation of macro calls.

.~UMMARY OF THE INVENTION

The present invention is an apparatus and method providing a compilation error m~ss~ge that specifically identifies a location of an 5 error during compilation of macro calls. The error mess~ge also provides a history of macro e~ncion for both simple macro calls and nested macro calls. Specifically, the present invention generates and prints a compilation error message identifying a location of the macro description that contains the compilation error. Furthermore, the 10 present invention generates a history of the eYp~ncion of the macro that caused the compilation error.
The present invention provides a method for co,lvel ling a source program to an object program, comprising the steps of: compiling the source program to yield the object program, wherein the source 15 program includes a macro definition and an instruction calling the macro defined in the macro definition, and wherein the compiling step includes the substep of exp~n~ling the instruction calling the macro;
generating history information representing the substep of expanding the macro, so that the locations in the source program of the macro 20 definition and the instruction calling the macro are saved; determining whether an error occurred when the macro was expanded during the compiling step; and printing an error message if an error occurred, in accordance with the history information, so that the error mess~ge sperific~lly identifies the location of the error within the source program 25 of the macro definition and of the instruction calling the macro.
Various advantages of the present invention will become more fully apparent when the following detailed description of the invention are read in conjunction with the accompanying drawings.

21709~9 -BRIEF DESCRIPIION OF THE DRAWINGS

The invention will now be described with reference to the accompanying drawings, wherein:
Fig. 1 is a block diagram of a computer system in accordance with a preferred embodiment of the present invention.
Fig. 2 shows formats of three tables stored in a memory of the computer system of Fig. 1.
Figs. 3(a), 3(b), 3(c), and 3(d) show detailed formats of entries lo in a source location table of Fig. 2.
Fig. 4 is an example of a source program.
Fig. 5 is an example of a tree data structure represented by the destin~tion and source tables created from the source program of Fig. 4.
Fig. 6 is an example of an error message output when the source program of Fig. 4 is compiled.
Fig. 7 is a flow chart showing steps performed during compilation of a source program to generate the source location table, the destination table, and the source table.
Fig. 8 is a flow chart showing further detail of Fig 7.
Fig. 9 is a flow chart showing steps performed during compilation of a source program to generate an error message reflecting the location in the source program of an error detected inside a macro expansion and a history of the macro expansion.
Figs. 10(a) and 10(b) show respective portions of tokens generated from the source program of Fig. 4.
Fig. 11 is an example of portions of a source location table generated from the source program of Fig. 4.
Fig. 12 is an example of a destination table generated from the source program of Fig. 4.

2170~9 Fig. 13 is an example of a source table generated from the source program of Fig. 4.

DETAILED DESCRIPIION OF THE PREFERRED

The following description is of the best presently contemplated modes of carrying out the invention. This description is made for the purpose of illustrating the general principles of the invention and is not to be taken in a limiting sense.
Fig. 1 is a block diagram of a computer system in accordance with a ~refelled embodiment of the present invention. Fig. 1 inchl(les a col..puler system 100, which includes a CPU 102 and a memory 104.
Computer system 100 may also contain various disk drives, printers, keyboards, input and output devices, and network connections, etc. (not shown). Memory 104 includes a compiler software program 106 (which includes a compiler preprocessor software program 108), a source program 110, an object program 111, and various tables and data structures 112, which are described in more detail below. As will be understood by a person of ordinary skill in the art, memory 104 also 20 contains an operating system (e.g., Unix) and various other software programs and data necessary for the functioning of computer system 100. These components are not shown for the sake of clarity.
Computer system 100 preferably is a Sun Microsystems' Sparcstation, or a col~u~er systems based on Intel's 80486 processor, the Power PC
25 processor, or Hewlett Packard's HP9000 processor, although other co~p.lters capable of perforn~ing the steps described below could also be used to implement the present invention.
Compiler 106 preferably are implemented in the Unix "lint"
code checker. The present invention can, however, be implemented in 3 o any system that compiles C-type macros. In a preferred embodiment, ` 2170~39 the present invention is invoked as an option from the comm~nd line of the lint preprocessor, although the present invention can be invoked in any a~lopliate m~nner.
Fig. 2 shows formats of threè tables stored in memory 104 of 5 computer system 100 of Fig. 1. These tables inrl~lde a source location table 202, a destination table 204, and a source table 206. As described below in more detail, source location table 202 holds the locations in source program 110 of tokens generated from source program 110 by preprocessor 108 during a compilation process. Source location table o 202 has tagged entries and each entry in source location table 202 indicates a location of a token in source program 110 being compiled (e.g., file, line number, and position within the line). Source location table 202 has a plurality of entries 208 having various formats as described below in connection with Fig. 3.
Destination table 204 and source table 206 also are generated by preprocessor 108 during compilation and are used to hold the "history" of macro expansion contained in source program 110.
Destination table 204 and source table 206 have formats as described below. The entries in each table are organized by ascending token 20 numbers, although not every token number may have an entry in tables 204 and 206.
Each entry 210 of destination table 204 has a format inchltling three fields. A first field 212 contains a token number of a source token. A second field 214 contains a token number of a destination 25 token. A third field 216 contains a length of a source token list that begins with the source token of that table entry. Examples of entries in the destin~tion table and a further description of its use are described in connection with Fig. 12.
Each entry 218 of source table 206 has a format in~hlfling three 3~ fields. A first field 220 contains a token number of a source token. A

--` 217093~

second field 222 contains a token number of a destination token. A
third field 224 CQnt~ins a length of the source token list that begins with the destin~tion token of that table entry. Examples of entries in the source table and a further description of its use are described in 5 connection with Fig. 13.
In a preferred embo~iment, the source and destin~tion tables require KN bytes of memory, where K is appro~;.,.~tely 9 through 12 and N is a number of macro calls contained in the source program.
Various known memory compression techniques can be used to save 0 memory storage space.
Figs. 3(a), 3(b), 3(c), and 3(d) show various formats of entries in source location table 202 of Fig. 2. In a preferred embodiment, the various entry formats are used to save space in source location table 202, but are not necessary for the operation of the invention. Source location table 202 contains an entry for each token in a line of the source program being compiled. Each entry indicates a location of the token in the source program. Each rect~n~ r box in Fig. 3 indicates a byte. Thus, the entries of source table 202 having the format of Figs.
3(a) and 3(b) contain one byte and the entries having the format of 20 Figs. 3(c) and 3(d) contain five bytes.
The format of Fig. 3(a) is used when a location of a token differs from that of a previous token only by its position within a line, i.e., when the file and the line number of the current token are the same as those of the previous token. As indicated in the Figure, if a 25 most significant bit in the entry is "0", then the entry represents a relative offset for position with a line. In the described embodiment, the offset can be between 0 and 7F (h~oY~decim~l), i.e., up to seven bits long. "X" in Fig. 3 indicates a "don't care" value.
The format of Fig. 3(b) is used when a token is located at a 30 different line number than the previous token, i.e., when the file 2170g~g number of the ~,~llrCll~ token is the same as that of the previous token.
The position within the line is ~csumed to be "1". As indi-~te~ in the Figure, if a most significant bit in the entry is "1" (and the first byte of the entry does not cont~in EF (hexadecimal) or FF (hexadecimal), then 5 the entry represents a relative offset for a line number. In the described embodiment, the offset can be between 0 and 7F
(hexadecimal), i.e., up to seven bits long.
The format of Fig. 3(c) is used when a location of a token differs from that of a previous token by more than a predetermined lo number of lines. As indicated in the Figure, if the first byte of the entry cont~inc FE (heY~decim~ then the entry is followed by four bytes cont~ining a line offset. In the described embodiment, the format of Fig. 3(c) is used if the line offset exceeds 125 lines because the format of Fig. 3(b) can only contain line offsets between 0 and 125. In the 5 described embodiment, the line offset may be between 0 and (hexadecimal), since four bytes are allocated for its storage.
The position within the line is assumed to be "1".
The format of Fig. 3(d) is used when a token is located in a different file than the previous token. As indicated in the Figure, if the 2 o first byte of the entry contains FF (hexadecimal), then the entry is followed by four bytes cont~ining a file number. In the described embo~iiment, the file number may be between 0 and ~
(hexadecimal) because four bytes are allocated for its storage. This number corresponds to a file name, as determined by a file name table 2s (not shown) stored in memory 104. The line number and position are assumed to be "1n.
In a preferred embo-liment the source location table is stored using ~lffm~n coding, in a m~nn~r known to persons of ordinary skill in the art, where each "deltan shown in Figs. 3(a) through 3(d) is stored 3() as a four bit value. Thus, the source location table requires ~N bytes 21709~9 of memory, where K is a small number appro~ tely between 0.5 and 1 and where N is a number of original source tokens. The represent~tion used to store the source and destination tables and the source location table are not the most important aspect of the present 5 invention, and any suitable storage representation can be used to implement the invention.
Fig. 4 is an example of a source program 400 written in the C
progr~mming language. Although the example given herein deals with macros in the C progr~mming l~n~1~ge, it should be understood that o the present invention can be implemented in a compiler for other compiled l~n~l~ge that includes C-like macros.
Source program 400 of Fig. 4 has three lines. A first line 402 is a macro definition for a first macro named "AA". The macro definition specifies that the body of macro AA calls an array named "ARn. A
15 second line 404 of the source program is a macro definition for a second macro named "B". The macro definition for B contains a call to a macro name passed as a parameter and a call to the macro A~ A
third line 406 of the source program is a definition of a variable "x" that contains a call to the macro B. Line 406 also passes the call of macro 20 AA to macro BB as a first argument. The source program does not include a definition for the array AR. Therefore, when compiler 108 compiles the source program, array AR is an undefined symbol. This undefined macro reference causes compiler 108 to generate an error mess~ge as shown in Fig. 6. This error message is generated in 25 accordance with the data structure of Fig. 5.
Fig. 5 shows a portion of a tree data structure created from the source prograrn of Fig. 4. Specifically, the tree shown in Fig. 5 shows the histoIy of the macro expansion for the syrnbol AR. In the described embodiment, the tree data structure is built in the destination and 30 source tables 204 and 206, although is should be understood that the 2170~

tree data structure oi Fig. S can be implemented using any al~propliate data structure or method. In Fig. 5, token AR is the head of the tree.
A left branch of the tree represents the destination of a macro when the macro is eYp~n-led during a macro call. Thus, following the left branch 5 in Fig. S, the array AR is used in the definition of macro AA (node 72), which is called in the definition c+AA(d) in macro B (where the symbol "c" is bound to "AAn) (node 66), which is called in the source program statement B(AA(y),z) (node 55). A right branch of the root node represents the source of the token AR (node 29). The right 10 branches of nodes 72 and 66 represent the sources of those macro calls.
Fig. 6 is an example of an error message generated when the source program of Fig. 4 is compiled in accordance with the present invention. When the compiler discovers an undefined symbol error for token AR, the compiler uses a recursive procedure known to persons of 15 ordinary skill in the art to traverse the tree of Fig. 5 to generate the macro history 602 shown in Fig. 6. The tree is traversed in a left to right, top to bottom order and each leaf of the tree represents a line in the error message. Thus, the compiler ~ccesses node 55 (the leftmost and lowest node of the tree) and prints the location in the source 2 o program that contains "int x=B(AA(y),z);n, i.e., line 3, file ex4.c, position 7 of the source program (see line 604 of the error mess~ge).
The compiler obtains the location of the node 55 from source location table 202, as described below. The other lines of macro history 602 in the error m~ss~ge are similarly generated by contin~ing to 25 traverse the tree and printing a line in the error mecc~ge for each leaf node in the tree. Thus, the lines of the source program corresponding to the leaves of the tree yield a history of the eYI~ncion of ~m~efined symbol AR. Lastly, the compiler prints the type of error discovered (here "error: undefined symbol: AR") as line 606 of the error m~ss~ge.

Figs. 7-13 show an implementation of the example in Figs. 4-6.
Figs. 7 and 8 are flow charts showing steps performed during compilation to create the tables of Figs. 11-13. Fig. 9 is a flow chart showing steps performed during compilation to generate an error message using the tables of Figs. 11-13. In the described embodiment, the steps of Figs. 7-9 are performed by CPU 102 executing software instructions, such as software instructions of preprocessor 108 (in compiler 108) or of compiler 108.
The steps of Figs. 7 and 8 are performed by preprocessor 108, as it pre-processes source program 400 and passes tokens to compiler 108 for compilation. In step 702, CPU 102 determines whether compiler 108 has requested information for additional lines of the source program. If so, CPU 102 inputs another line of source program 400 in step 704. In step 706, tbe new line of the source program is "tokenized" in a manner known to persons of ordinary skill in the art.
During tokenization, the source program is broken down into tokens and the tokens are numbered. In the described embodiment, tokenization is performed in conformance with ISO (International Standards Org~ni7~tion) Standard 9899. Tokenizing source program 2 o 400 results in tokens such as those shown in Figs. 10(a) and 10(b). Inthe described embodiment, preprocessor 108 tokenizes one line of the source program at a time and sends the tokens to compiler 108 for compilation. Thus, Fig. 10 is inclucled herein for the sake of example, and may not exist in its entirety at any time during compilation.
If, in step 708, not all tokens in the current line of the source program line have been processed, control passes to step 709. In step 709 a new current token is placed in a token list (not shown) in memory 104. In step 710, the location of the token is entered into source location table 1102 of Fig. 11. Source location table 1102 contains the 3o location in source program 400 for each token. Fig. 11 shows a portion of source location table 1102 for source program 400. It will be understood by persons of ordinary skill in the art that source location table 1102 may be implernerlted using any format that allows the compiler to identify a location in the source program for various tokens.
For example, in Fig. 11, source location table 1102 indicates that token number 29 (the token -ARn) is located at line 1, position 15 in source program 400. Similarly, token number 44 (the token "cn) is located at line 2, position 16; token number 55 (the token "Bn) is located at line 3, position 7; and token number 57 (the token "AA") is located at line 3, position 9. The tokens shown in Fig. 11 correspond to the leaves of the tree structure of Fig. 5. It should be understood that source location table 1102 includes other entries, i.e., one entry for each token in source program 400. There are no entries in source location table 1102 corresponding to the interior nodes of the tree. These nodes have entries in the source and destin~tion tables.
If, in step 712, the next token is the beginning of a macro call, control passes to step 714. Other~vise control returns to step 708. In step 714, preprocessor 108 expands the macro and places the result of the expansion in the token list that will be used by compiler 108.
2 o The steps of Fig. 8, which are performed each time a macro expansion occurs during compilation, save the history of the macro expansion in destination table 1202 and in source table 1302. In step 716 CPU 102 saves the history of a macro ~ ncion by placing an entry in each of destination table 1202 and source table 1302 for each macro 2 5 eYp~nsion performed. Nested macro calls result in multiple entries in the destination and source tables, as in the example. Details of step 716 are shown in Fig. 8. Each time a macro is expanded by preprocessor 108, three values are entered in destin~tion table 1202 and three values are entered in source table 1302, respectively.

217U~9 An example of a nested macro eYI~ncion is given below. The source ~rogl~ll st~tçment "B(AA(Y),z)~ co~le~l~onds to tokens 55-62.
This source prograrn statement is expanded to "c+AA(d)" (tokens 66-71), where "c" is eYp~nded to "AA(y)" (tokens 72-75), which is in turn eYr~nded to "AR" (token 76). Inspection of the tree structure of Fig. S
shows that the left branches of the tree correspond to this eYr~nsion.
Further inspection of destin~tion table 1202 of Fig. 12 shows that the first three entries in the table of Fig. 12 correspond to the three left branches of the tree. In a similar manner, the first three entries in the table of Fig. 13 correspond to the three right branches of the tree. The right branches represent the "source" of the macro calls.
The entries shown in Figs. 12 and 13 are created in accordance with the flow chart of Fig. 8 and have a format shown in Fig. 2. The tree of Fig. 5 (as represented by the table entries of Figs. 12 and 13) is created upwardly from its lower leftmost leaf. Thus, for the macro call "B(AA(y),z)n, an token value of 55 is placed in the Dst field of a current entry of the destination table 1202 (step 802). Because the macro call is eYp~nded as "c+AA(d)" a token value of 66 and a length of 6 also are placed in the Src and Len fields of the current entry of destination table 1202 (steps 804 and 806).
Next, since the character string "c+AA(d)" contains 6 tokens, a token number of 66 and a length of 6 are placed in a the Dst and Len fields of a current entry of source table 1302 (steps 808 and 812).
Because the character string "c" has a source of "c+AA(d)" the token 44 is placed in the Src field of the current entry of source table 1302 (step 810). These six steps are repeated for the eYp~n~ion of "c" into "AA(y)"
and for the eYr~n~ion of "AA(y)" into "AR" to yield the first three entries in tables 1202 and 1302. Tables 1202 and 1302 also show additional entries not ~iis~lssed herein in detail. Similarly, the entries for the expansion of, e.g., "AA(d)" (line 2, position 18) is not shown in the example, but is performed in a manner similar to that described above.
Retull.ing to Fig. 7, after step 716, control returns to step 708.
If all the tokens on a current line of the source program have been 5 proce-sse~l, the token list for the current line is sent to the compiler (see Fig. 9) and control returns to step 702.
Fig. 9 is a flow chart showing steps performed during compilation to generate an error mess~ge. Compiler 108 generates any error mess~ges in accordance with the present invention. The general 10 operation of compiler 108 is known to persons of ordinary skill in the art and will not be licc~lssed herein. If the CPU (in step 902) detects a compilation error that occurs within a macro expansion (step 904), the CPU prints a history of the macro eYp~ncion using the destination and source tables (in step 906). Specifically, the compiler calls an error 15 routine that traverses the tree stored in the destination and source tables that has a root node corresponding to the error (e.g., the undefined symbol). The tree is traversed from top to bottom and from left to right. Thus, for example, when compiler 108 determines that "AR" is an undefined symbol, it prints the error message of Fig. 6 in 20 accordance with leaves of the tree of Fig. S.
For example, the left branches of the tree are traversed by starting at an entry corresponding to the root node and repeatedly searching destination table 1202 for subsequent nodes until a first entry is found that does not have a corresponding second entry with a Src 25 field contents equal to the Dst field of the first entry (e.g., the first entry in destin~tion table 1202). When this event occurs, the Dst field represents a leaf node and the location of the leaf node is obtained from source location table 1102. Tree traversal is well understood by persons of ordinary skill in the art and will not be described in detail herein. Lastly, in step 908 the compiler prints a mecc~ge that identifies the typ,e of error found, as shown in Fig. 6 (e.g., "undefined symbol").
In s~ , printing a history of the macro exp~ncion for the macro in which a compilation error occurred and specifically identifying 5 the location of the error within a macro definition provides helpful infollllation during compilation, which in turn leads to faster and more efficient development of colllputer programs.
Several preferred embodiments of the present invention have been described. Nevertheless, it will be understood that various 10 modifications may be made without departing from the spirit and scope of the invention. For example, other orders of macro substitution history tree tracing could be used. Tncte~d of printing source lines and error messages on paper, the compiler could display them using a graphical user interface in a text editor window of an integrated 15 development environment. ~ncte~d of storing the source location table, the second pass on the source text by the preprocessor could be used for restoring the source location of any token. This last modification would signi~lcantly reduce the amount of memory required.
In describing the preferred embodiments, a number of specific 20 technologies used to implement the embodiments of various aspects of the invention were identified and related to more general terms in which the invention was described. However, it should be understood that such specificity is not intended to limit the scope of the claimed invention.

Claims (20)

1. A method for converting a source program to an object program, comprising the steps, performed by a computer system, of:
compiling the source program to yield the object program, wherein the source program includes a macro definition and an instruction calling a macro defined in the macro definition, and wherein the compiling step includes the substep of expanding the instruction calling the macro;
generating history information in a memory, the history information representing the substep of expanding the macro, so that the locations in the source program of the macro definition and of the instruction calling the macro are saved;
determining whether an error occurred when the macro was expanded during the compiling step; and printing an error message if an error occurred, in accordance with the history information, so that the error message specifically identifies the location of the error within the source program of the macro definition and the location within the source program of the instruction calling the macro.
2. The method of claim 1, wherein the printing step further includes the step of printing a message identifying a type of error that occurred when the macro was expanded during the compiling step.
3. The method of claim 1, wherein the source program is written in the C programming language.
4. The method of claim 1, wherein the history generating step incudes the step of generating history information in which a character string in the source program is represented by a single, unique token number.
5. The method of claim 1, wherein the determining step includes the step of determining a location of the compilation error and wherein the location of the compilation error is represented by a single, unique token number stored in a table in the memory.
6. The method of claim 1, wherein the history information includes a tree data structure storing the source and destination of the macro expansion performed during the compilation step.
7. The method of claim 1, wherein the history information is stored in a destination table and a source table in the memory.
8. The method of claim 7, wherein the destination table and the source table require KN bytes of memory, where K =9 through 12 and N is the number of macro calls contained in the source program.
9. The method of claim 1, wherein the locations of tokens in the source program are stored in a source location table.
10. The method of claim 9, wherein the source location table requires KN bytes of memory, where K is a number between 0.5 and 1 and N is a number of original source tokens in the source program.
11. The method of claim 1, wherein the printing step includes the step of printing an error message that specifically identifies the file name, line number, and position of the error in the macro definition and the file name, line number, and position of the instruction calling the macro.
12. The method of claim 1, wherein the source program includes a second macro definition and a nested instruction calling a second macro defined in the second macro definition, wherein the nested instruction is within the first macro definition, wherein the compiling step includes the substep of expanding the instruction calling the first and second macros;
wherein the history generating step saves the locations in the source program of the first and second macro definitions and of the first and second instructions calling the macros;

wherein the determining step includes the step of determining whether an error occurred when the second macro was expanded during the compiling step; and wherein the printing step incudes the step of printing an error message if an error occurred, in accordance with the history information, so that the error message specifically identifies the location of the error within the source program of the second macro definition and the location of the first and second instructions.
13. An apparatus for converting a source program to an object program, comprising:
a memory storing the source program;
a compiler portion, coupled to the memory that compiles the source program to yield the object program, wherein the source program includes a macro definition and an instruction calling a macro defined in the macro definition, wherein the compiler portion expands the instruction calling the macro;
a history generator, coupled to the memory that generates history information that is stored in the memory, the history information representing expansion of the macro, so that the locations in the source program of the macro definition and of the instruction calling the macro are saved;
a determining portion, coupled to the compiler portion and determining whether an error occurred when the macro was expanded during compilation; and a printing portion that prints an error message if an error occurred during compilation, in accordance with the history information, so that the error message specifically identifies the location of the error within the source program of the macro definition and the location within the source program of the instruction calling the macro.
14. The apparatus of claim 13, wherein the printing portion also prints a message identifying a type of error that occurred when the macro was expanded during compilation.
15. The apparatus of claim 13, wherein the history generator generates history information in which a character string in the source program is represented by a single, unique token number.
16. The apparatus of claim 13, wherein the determining portion determines a location of the compilation error and wherein the location of the compilation error is represented by a single, unique token number stored in a table in the memory.
17. The apparatus of claim 13, wherein the locations of tokens in the source program are stored in a source location table in the memory.
18. The apparatus of claim 13, wherein the history information includes a tree data structure storing the source and destination of the macro expansion performed during compilation.
19. The apparatus of claim 13, wherein the printing portion prints an error message that specifically identifies the file name, line number, and position of the error in the macro definition and the file name, line number, and position of the instruction calling the macro.
20. The apparatus of claim 13, wherein the source program includes nested macro calls;
wherein the compiler portion expands the nested macro calls;
wherein the history generator saves the locations in the source program of the nested macro calls;
wherein the determining portion determines whether an error occurred when the nested macro calls were expanded during compilation; and wherein the printing portion prints an error message if an error occurred, in accordance with the history information, so that the error message specifically identifies the location of the error within the source program of the nested macro calls.
CA002170939A 1995-03-27 1996-03-04 Method and apparatus for displaying locations of errors detected inside software macro calls Abandoned CA2170939A1 (en)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US08/410,672 US5701487A (en) 1995-03-27 1995-03-27 Method and apparatus for displaying locations of errors detected inside software macro calls
US410,672 1995-03-27

Publications (1)

Publication Number Publication Date
CA2170939A1 true CA2170939A1 (en) 1996-09-28

Family

ID=23625725

Family Applications (1)

Application Number Title Priority Date Filing Date
CA002170939A Abandoned CA2170939A1 (en) 1995-03-27 1996-03-04 Method and apparatus for displaying locations of errors detected inside software macro calls

Country Status (5)

Country Link
US (1) US5701487A (en)
EP (1) EP0735466A3 (en)
JP (1) JPH08314728A (en)
KR (1) KR960035260A (en)
CA (1) CA2170939A1 (en)

Families Citing this family (37)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5903859A (en) * 1996-03-27 1999-05-11 Dell Usa, L.P. Dynamic multi-lingual software module system
US5948107A (en) * 1997-05-28 1999-09-07 Intel Corporation Method of handling errors in complex inheritance hierarchies
US5978587A (en) * 1997-11-13 1999-11-02 Unisys Corp. Method for propagating source code locations into objects in a compiler
US5978586A (en) * 1997-11-26 1999-11-02 Unisys Corp. Method for tracking changes in source locations in a compiler
US6219828B1 (en) * 1998-09-30 2001-04-17 International Business Machines Corporation Method for using two copies of open firmware for self debug capability
US6654953B1 (en) * 1998-10-09 2003-11-25 Microsoft Corporation Extending program languages with source-program attribute tags
CN1359489A (en) * 1998-10-16 2002-07-17 联合想象计算机公司 Method and system for an extensible macro language
US6353924B1 (en) * 1999-02-08 2002-03-05 Incert Software Corporation Method for back tracing program execution
US6381736B1 (en) * 1999-10-12 2002-04-30 Cisco Technology, Inc. Method for compile-time type-checking of arguments for externally-specified format strings
US7734457B2 (en) * 1999-10-16 2010-06-08 Computer Associates Think, Inc. Method and system for generating dynamic comparison models
US6715109B1 (en) 2000-02-04 2004-03-30 International Business Machines Corporation Method, computer program product, and system for making standard stream data accessible that would otherwise be lost in application programs
US6708333B1 (en) * 2000-06-23 2004-03-16 Microsoft Corporation Method and system for reporting failures of a program module in a corporate environment
US8032886B2 (en) * 2000-11-22 2011-10-04 Microsoft Corporation Tracking asynchronous execution of program using hierarchical structure of objects
US6813707B1 (en) * 2001-03-23 2004-11-02 Cisco Technology Inc. Enhancing instruction execution using built-in macros
US6931627B2 (en) * 2001-05-16 2005-08-16 Sun Microsystems, Inc. System and method for combinatorial test generation in a compatibility testing environment
US20030088810A1 (en) * 2001-11-02 2003-05-08 Sun Microsystems, Inc. Methods and apparatus for determining software component sizes associated with errors
US7337438B1 (en) 2003-03-31 2008-02-26 Applied Micro Circuits Corporation Macros to support structures for an assembler that does not support structures
US7571431B2 (en) * 2003-04-29 2009-08-04 Microsoft Corporation Processing macro information and displaying via GUI in different tools
EP1652074A4 (en) * 2003-07-11 2008-08-13 Computer Ass Think Inc Adding user-defined objects to a modeling tool
US8171482B1 (en) 2006-05-09 2012-05-01 Vmware, Inc. Application environment specifications for provisioning application specific runtime environments using subsets of resources required for execution
KR20080045545A (en) * 2006-11-20 2008-05-23 삼성전자주식회사 Method of pre-processing conditional region
US8863148B1 (en) * 2007-01-09 2014-10-14 Marvell International Ltd. Small debug print
US8219987B1 (en) 2007-08-24 2012-07-10 Vmware, Inc. Optimized virtual machine specification for provisioning application specific runtime environment
US8577937B1 (en) 2007-05-09 2013-11-05 Vmware, Inc. Repository including exclusion list
US11262996B2 (en) 2007-05-09 2022-03-01 Vmware, Inc. Repository including exclusion list
US9015180B1 (en) 2007-05-09 2015-04-21 Vmware, Inc. Repository including file identification
US8347263B1 (en) 2007-05-09 2013-01-01 Vmware, Inc. Repository including installation metadata for executable applications
US8001083B1 (en) 2007-05-09 2011-08-16 Vmware, Inc. Repository including version management
US7971047B1 (en) 2007-09-10 2011-06-28 Vmware, Inc. Operating system environment and installation
US8171141B1 (en) 2009-04-02 2012-05-01 Vmware, Inc. Provisioning system including stack manager
US8473902B2 (en) * 2009-08-07 2013-06-25 International Business Machines Corporation Identifying source code elements for refactoring
JP5385102B2 (en) * 2009-11-24 2014-01-08 株式会社野村総合研究所 Source analysis program, preprocessor, lexer, and syntax tree analysis program
JP5385103B2 (en) * 2009-11-24 2014-01-08 株式会社野村総合研究所 Macro expansion method and preprocessor
US8863094B2 (en) * 2010-05-18 2014-10-14 International Business Machines Corporation Framework for a software error inject tool
CN102855306B (en) * 2012-08-21 2015-04-15 飞天诚信科技股份有限公司 Method and device for parsing source file
US10614432B2 (en) * 2016-01-29 2020-04-07 Ncr Corporation Channel integration processing
US10176104B2 (en) * 2016-09-30 2019-01-08 Arm Limited Instruction predecoding

Family Cites Families (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US4931928A (en) * 1988-11-09 1990-06-05 Greenfeld Norton R Apparatus for analyzing source code
US4916810A (en) * 1989-05-12 1990-04-17 Amp Incorporated Method and apparatus for terminating wires to terminals
JPH03126133A (en) * 1989-10-11 1991-05-29 Matsushita Electric Ind Co Ltd Compiler processing method
US5293629A (en) * 1990-11-30 1994-03-08 Abraxas Software, Inc. Method of analyzing computer source code

Also Published As

Publication number Publication date
JPH08314728A (en) 1996-11-29
KR960035260A (en) 1996-10-24
US5701487A (en) 1997-12-23
EP0735466A2 (en) 1996-10-02
EP0735466A3 (en) 1997-05-02

Similar Documents

Publication Publication Date Title
US5701487A (en) Method and apparatus for displaying locations of errors detected inside software macro calls
KR930008769B1 (en) System for generating software source code component
EP0413486A2 (en) Message processing system
US9710243B2 (en) Parser that uses a reflection technique to build a program semantic tree
US6434742B1 (en) Symbol for automatically renaming symbols in files during the compiling of the files
US5832273A (en) System for deleting redundant instructions from high level language source code containing in-line assembly instructions
US20080007779A1 (en) Method and system for generating executable code for formatting and printing complex data structures
WO1993025963A1 (en) Debugger program which includes correlation of computer program source code with optimized objet code
WO2003094007A1 (en) System and method for transformation of xml documents using stylesheets
EP0520708B1 (en) Method and apparatus for converting high level form abstract syntaxes into an intermediate form
US5758163A (en) Method and apparatus for record fields usage checking at compile time
US6381736B1 (en) Method for compile-time type-checking of arguments for externally-specified format strings
NO329240B1 (en) System and method for explanatory definition and use of document encoding subgroups
KR20030015200A (en) Robust logging system for embedded systems for software compilers
US20010051974A1 (en) Method and apparatus for automatic generation of data interfaces
JP3418544B2 (en) Automatic test data generator for programs
KR100417655B1 (en) Regulating information generator and program development system composed of regulator
CN107577476A (en) A kind of Android system source code difference analysis method, server and medium based on Module Division
JP3596570B2 (en) Method of allocating classes to main storage
KR100279731B1 (en) How to Display Control Flow for Fill Languages
JPH06266562A (en) Object code size optimizing system in object-oriented language processing system
JPH03100730A (en) Method for emergency correction data generation processing with high grade language
JPH04148336A (en) Fortran program grammar analyzing system
JPH03186933A (en) Symbol processing system for language processing system
JPH10154079A (en) Program conversion device and storage medium

Legal Events

Date Code Title Description
FZDE Discontinued