CN111158694A - Compiling alarm processing method and device - Google Patents
Compiling alarm processing method and device Download PDFInfo
- Publication number
- CN111158694A CN111158694A CN201911315930.5A CN201911315930A CN111158694A CN 111158694 A CN111158694 A CN 111158694A CN 201911315930 A CN201911315930 A CN 201911315930A CN 111158694 A CN111158694 A CN 111158694A
- Authority
- CN
- China
- Prior art keywords
- alarm
- information
- feature
- code
- characteristic
- 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.)
- Pending
Links
- 238000003672 processing method Methods 0.000 title claims abstract description 16
- 238000012545 processing Methods 0.000 claims abstract description 17
- 238000000034 method Methods 0.000 abstract description 18
- 230000009286 beneficial effect Effects 0.000 abstract description 4
- 238000012360 testing method Methods 0.000 description 11
- 230000006870 function Effects 0.000 description 9
- 230000004048 modification Effects 0.000 description 9
- 238000012986 modification Methods 0.000 description 9
- 230000008569 process Effects 0.000 description 6
- 238000000605 extraction Methods 0.000 description 4
- 238000011161 development Methods 0.000 description 3
- 238000010586 diagram Methods 0.000 description 3
- 230000008859 change Effects 0.000 description 2
- 238000004590 computer program Methods 0.000 description 2
- 238000005516 engineering process Methods 0.000 description 2
- 239000000284 extract Substances 0.000 description 2
- 230000003287 optical effect Effects 0.000 description 2
- 230000005540 biological transmission Effects 0.000 description 1
- 238000012423 maintenance Methods 0.000 description 1
- 230000004044 response Effects 0.000 description 1
- 230000003068 static effect Effects 0.000 description 1
Images
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F8/00—Arrangements for software engineering
- G06F8/40—Transformation of program code
- G06F8/41—Compilation
- G06F8/43—Checking; Contextual analysis
Landscapes
- Engineering & Computer Science (AREA)
- General Engineering & Computer Science (AREA)
- Theoretical Computer Science (AREA)
- Software Systems (AREA)
- Physics & Mathematics (AREA)
- General Physics & Mathematics (AREA)
- Debugging And Monitoring (AREA)
Abstract
The invention provides a compiling alarm processing method and device, which shorten the time consumption required by compiling alarm processing and are beneficial to improving the accuracy of processing. The method comprises the following steps: acquiring a feature set, wherein the feature set comprises the features of each first alarm message generated when a first source code is compiled; determining the characteristics of each second alarm message generated when a second source code is compiled, wherein the second source code is the modified source code of the first source code; for the characteristic of each second alarm message, checking whether the characteristic exists in the characteristic set, and if not, determining that the characteristic is a target characteristic; and outputting second alarm information corresponding to each target characteristic.
Description
Technical Field
The invention relates to the technical field of software, in particular to a compiling alarm processing method and device.
Background
Compiling alarms means that alarm (Warning) information is output during the process of compiling source codes by a compiler (such as GCC). Alarm information is typically generated in the event that the code format is written unnormally, there are redundant code operations, incorrect code that a compiler considers to be suspicious, etc. The alarm information can help software developers to discover hidden errors in source code and optimize the code.
A large software development project is composed of thousands of source code files, which are divided into different modules according to different functional characteristics, and the different modules are usually maintained by different development teams. During development and maintenance, the development team for each module typically only modifies the module in charge, but at compile time may need to compile the source code files for all modules to generate a complete software package. When compiling source code files for all modules, the following problems may be faced:
for example, a module modified by a developer generates only one alarm message, while other modules generate more than two hundred alarm messages, and in order to determine whether the modified module introduces new alarm messages, all the alarm messages need to be checked once to find out the new alarm messages from the more than two hundred alarm messages. In addition, if a developer modifies a common code header file, it may affect the source files of multiple modules to compile alarms, which makes it more difficult to determine which alarms are introduced by the current modification.
Therefore, in the above manner, the alarm compiling process is time-consuming, and the manual search risks missing.
Disclosure of Invention
In view of this, the present invention provides a method and an apparatus for processing a compiling alarm, which shorten the time consumption required for processing the compiling alarm and are beneficial to improving the accuracy of the processing.
The first aspect of the present invention provides a compiling alarm processing method, including:
acquiring a feature set, wherein the feature set comprises the features of each first alarm message generated when a first source code is compiled;
determining the characteristics of each second alarm message generated when a second source code is compiled, wherein the second source code is the modified source code of the first source code;
for the characteristic of each second alarm message, checking whether the characteristic exists in the characteristic set, and if not, determining that the characteristic is a target characteristic;
and outputting second alarm information corresponding to each target characteristic.
According to one embodiment of the invention, determining the characteristics of each second alarm message generated when the second source code is compiled comprises:
and for each second alarm message, extracting the file name to be alarmed, the code information to be alarmed and the alarm reason information from the second alarm message, and taking the extracted file name, code information and alarm reason information as the characteristics of the second alarm message.
According to one embodiment of the invention, extracting code information from the second alarm information comprises:
checking whether the alarm reason information in the second alarm information represents a redefined identifier;
if yes, extracting an identifier from the second alarm information, and taking the extracted identifier as code information;
and if not, extracting a code statement from the second alarm information, and taking the extracted code statement as code information.
In accordance with one embodiment of the present invention,
the features include: the file name of the alarmed file, the code information of the alarmed file and the reason information of the alarm, wherein the code information comprises an identifier or a code statement;
checking whether the feature exists in the feature set, including:
checking whether a first feature containing a file name in the feature exists in the feature set;
if yes, determining whether the feature exists in the feature set according to code information and alarm reason information contained in the feature;
if not, determining that the feature does not exist in the feature set.
According to an embodiment of the present invention, determining whether the feature exists in the feature set according to the code information and the alarm reason information included in the feature includes:
checking whether at least one target first feature containing code information in the feature exists in all the first features;
if yes, determining that the feature exists in the feature set when the alarm reason information in any one target first feature is the same as the alarm reason information in the feature; when the alarm reason information in all the target first characteristics is different from the alarm reason information in the characteristics, determining that the characteristics do not exist in the characteristic set;
if not, determining that the feature does not exist in the feature set.
A second aspect of the present invention provides a compiling alarm processing apparatus, including:
the characteristic set acquisition module is used for acquiring a characteristic set, wherein the characteristic set comprises the characteristics of each first alarm message generated when the first source code is compiled;
the characteristic determining module is used for determining the characteristic of each second alarm message generated when a second source code is compiled, wherein the second source code is the modified source code of the first source code;
the target characteristic determining module is used for checking whether the characteristic exists in the characteristic set or not aiming at the characteristic of each second alarm message, and if not, determining that the characteristic is the target characteristic;
and the alarm information output module is used for outputting second alarm information corresponding to each target characteristic.
In accordance with one embodiment of the present invention,
the features at least include: code information to be alerted;
when the characteristic determining module determines the characteristic of each second alarm information generated when the second source code is compiled, the characteristic determining module is specifically configured to:
and for each second alarm message, extracting the file name to be alarmed, the code information to be alarmed and the alarm reason information from the second alarm message, and taking the extracted file name, code information and alarm reason information as the characteristics of the second alarm message.
According to an embodiment of the present invention, when the feature determining module extracts the code information from the second warning information, the feature determining module is specifically configured to:
checking whether the alarm reason information in the second alarm information represents a redefined identifier;
if yes, extracting an identifier from the second alarm information, and taking the extracted identifier as code information;
and if not, extracting a code statement from the second alarm information, and taking the extracted code statement as code information.
In accordance with one embodiment of the present invention,
the features include: the file name of the alarmed file, the code information of the alarmed file and the reason information of the alarm, wherein the code information comprises an identifier or a code statement;
when the target feature determining module checks whether the feature exists in the feature set, the target feature determining module is specifically configured to:
checking whether a first feature containing a file name in the feature exists in the feature set;
if yes, determining whether the feature exists in the feature set according to code information and alarm reason information contained in the feature;
if not, determining that the feature does not exist in the feature set.
According to an embodiment of the present invention, when the target feature determining module determines whether the feature exists in the feature set according to the code information and the alarm reason information included in the feature, the target feature determining module is specifically configured to:
checking whether at least one target first feature containing code information in the feature exists in all the first features;
if yes, determining that the feature exists in the feature set when the alarm reason information in any one target first feature is the same as the alarm reason information in the feature; when the alarm reason information in all the target first characteristics is different from the alarm reason information in the characteristics, determining that the characteristics do not exist in the characteristic set;
if not, determining that the feature does not exist in the feature set.
The embodiment of the invention has the following beneficial effects:
in the embodiment of the invention, after the source code is modified, the feature set formed by the features of all the first alarm information generated when the source code before modification, such as the first source code, is compiled is obtained, and the features of the second alarm information generated when the modified source code, such as the second source code, is compiled are compared with the feature set to find out the new alarm information introduced by the modification, so that the new alarm information does not need to be manually found out, the time consumption for determining the new alarm information is shortened, the workload of developers is reduced, and the inaccuracy caused by manually checking the alarm information can be avoided.
Drawings
FIG. 1 is a flow chart illustrating a compiled alarm processing method according to an embodiment of the present invention;
FIG. 2 is a block diagram of a compiling alarm processing apparatus according to an embodiment of the invention;
fig. 3 is a block diagram of an electronic device according to an embodiment of the present invention.
Detailed Description
Reference will now be made in detail to the exemplary embodiments, examples of which are illustrated in the accompanying drawings. When the following description refers to the accompanying drawings, like numbers in different drawings represent the same or similar elements unless otherwise indicated. The embodiments described in the following exemplary embodiments do not represent all embodiments consistent with the present invention. Rather, they are merely examples of apparatus and methods consistent with certain aspects of the invention, as detailed in the appended claims.
The terminology used herein is for the purpose of describing particular embodiments only and is not intended to be limiting of the invention. As used in this specification and the appended claims, the singular forms "a", "an", and "the" are intended to include the plural forms as well, unless the context clearly indicates otherwise. It should also be understood that the term "and/or" as used herein refers to and encompasses any and all possible combinations of one or more of the associated listed items.
It should be understood that although the terms first, second, third, etc. may be used herein to describe various ports, this information should not be limited to these terms. These terms are only used to distinguish one type of device from another. For example, a first port may also be referred to as a second port, and similarly, a second port may also be referred to as a first port, without departing from the scope of the present invention. The word "if" as used herein may be interpreted as "at … …" or "when … …" or "in response to a determination", depending on the context.
There are various kinds of alarm information generated when the source code is compiled, and three kinds are listed as follows:
the first method comprises the following steps: redundant variable definitions. For example, a variable int x is defined, but the normal operation result of the program is not affected by not using the variable, but the definition may be deleted to reduce the code, and the compiler may output an alarm message:
test.c:7:9:warning:unused variable‘x’[-Wunused-variable]
int x；
^
and the second method comprises the following steps: uninitialized variables are used. For example, the variable x [5] is not initialized, so the initial value is an unknown random value, which may cause an unexpected result, and the compiler outputs an alarm:
test.c:12:5:warning:‘x[5]’is used uninitializedin this function[-Wuninitialized]
printf("b％lf,c％lf,sum％lf,％d\n",b,c,(b+c),x[5])；
^
and the third is that: if conditions the expression is forever true within brackets. For example, if (a ═ 1) is written, and if one is not written, the compiler outputs an alarm message:
test.c:14:5:warning:suggest parentheses around assignment used astruth value[-Wparentheses]
if(a＝1)
^
the alarm information generated when the source code is compiled is strongly associated with the source code, the compiler version and the compiling parameter, the same source code uses different compiling parameters or the alarm information generated when the source code is compiled under different environments (such as a Linux environment and a windows environment) is not completely consistent, the first alarm information cannot be generated when the GCC of the low version is compiled, and similar alarms can be generated when the source code is compiled by using a newer version GCC.
Therefore, not all alarm information needs to be eliminated, for example, if a code contains some stable open source code libraries, the code has no problem, but only some alarm information exists due to inconsistency of the compiling environment, and in order to maintain the integrity of the open source code, the alarms are not generally eliminated; when the GCC version is just upgraded or a new architecture is compiled, some alarm information may be generated due to different compiling environments; there is also a small amount of alarm information that may be due to compiler misinformation or that is not necessarily eliminated. These do not result in source code errors.
However, when the alarm information is generated, if the alarm information is not processed at all, some errors may be hidden in the source code, and some fatal alarm information is easily ignored, for example, the alarm information indicates that a code logic problem, such as the second alarm information, is not found and modified in time, and finally, serious destructiveness is brought to software stability.
Therefore, after the developer modifies the source code based on the previous source code and compiles the modified source code, it is necessary to confirm whether the modified module introduces new warning information and determine whether the new warning information is fatal, and the previous source code may have more warning information, so that it is time-consuming to manually find out new warning information from the more warning information, and it is easy to check and omit new warning information.
The embodiment of the invention can reduce the time consumption for searching new alarm information and is beneficial to improving the working efficiency and the code quality.
The following describes the compiling alarm processing method according to the embodiment of the present invention in detail, but the present invention should not be limited thereto.
In one embodiment, referring to fig. 1, compiling an alarm handling method may include the steps of:
s100: acquiring a feature set, wherein the feature set comprises the features of each first alarm message generated when a first source code is compiled;
s200: determining the characteristics of each second alarm message generated when a second source code is compiled, wherein the second source code is the modified source code of the first source code;
s300: for the characteristic of each second alarm message, checking whether the characteristic exists in the characteristic set, and if not, determining that the characteristic is a target characteristic;
s400: and outputting second alarm information corresponding to each target characteristic.
In the embodiment of the present invention, an execution main body of the compiled alarm processing method may be an electronic device, and the electronic device may be a computer device. Of course, the specific type of the electronic device is not limited as long as it has certain data processing capability.
In step S100, a feature set is obtained, where the feature set includes features of each first alarm information generated when the first source code is compiled.
The feature set may be downloaded from a code server. The feature set and the first source code can be correspondingly stored in the code server, and the corresponding first source code can be downloaded while the feature set is downloaded, and the first source code and the feature set can be stored in the electronic device.
The developer can modify the first source code to obtain a second source code. The first source code may be a source code that has already been issued, preferably a source code of a latest version that is issued, and is not limited in particular.
It will be appreciated that the first source code and the second source code may each comprise a plurality of code files, for example, the first source code may comprise code files having file names code _ a.c, code _ b.c, code _ c.c, etc. The developer may modify one or several of the code files, such as only the code file with the file name code _ a.c in the first source code, and the other code files in the first source code and the modified code file with the file name code _ a.c as the second source code.
When the alarm information newly generated when the second source code is compiled needs to be determined, the saved feature set can be directly obtained from the electronic equipment locally.
The feature set contains features of each first alarm message generated when the first source code is compiled, and specifically, the feature set can be determined by:
acquiring all first alarm information generated when the first source code is compiled;
extracting features from each piece of first alarm information, wherein the features can comprise the name of the file to be alarmed, the code information of the alarmed, the reason information of the alarm and the like in the piece of first alarm information;
and composing all the extracted features into a feature set.
The feature set may be saved via a text file, such as may be saved in waning _ b.txt.
The characteristics of the first warning information are not limited to those described above as long as the first warning information can be characterized. Taking the following first warning information as an example, the following feature extraction method is described:
test.c:7:9:warning:unused variable‘x’[-Wunused-variable]
int x
^
extracting 'test.c' in the alarm information as a file name contained in the characteristics (the file names all have a specific format, for example, suffixes are all.c or.h, etc., and can be extracted according to the format of the file name); extracting a code statement 'int x' as code information contained in the feature (the code statement appears in a sentence before 'Lambda' of the alarm information and can be extracted according to the position of the code statement in the alarm information); the "unused variable 'x' [ -wunsused-variable ]" of the alarm information is extracted as the alarm cause information contained in the feature (the alarm cause information is located after the "warning" of the alarm information, and may be extracted according to the position of the alarm cause information in the alarm information), and of course, only the "unused variable 'x'" before the "[" may be extracted as the alarm cause information contained in the feature.
That is, the characteristics of the first warning information (abbreviated as characteristics a1) are "test.c", "int x", "unused variable 'x'".
The above is merely an example of the feature extraction method, and it is needless to say that the features may be extracted in other methods.
In step S200, the characteristics of each second warning message generated when the second source code is compiled are determined.
And the developer obtains a second source code after modifying the first source code. In other words, the second source code is the modified source code of the first source code. The number of the modified code files, the modified code amount and the modified times are not limited.
The compiler can be used for compiling the second source code, the second alarm information generated in the compiling process can be stored in a local file such as local _ warning.txt, and after all code files of the second source code are compiled, the characteristics of each second alarm information in the local _ warning.txt can be determined. For example, each second alarm information in local _ warning.txt may be traversed, and a feature may be extracted from the traversed second alarm information as a feature of the second alarm information.
The feature of the second warning information may be extracted from the second warning information in the same manner as the feature extraction of the first warning information. The characteristic of the second warning information may be used to characterize the second warning information.
When the first alarm information and the second alarm information are the same, the characteristics of the first alarm information are the same as those of the second alarm information. Of course, since some information in the alarm information, such as the row number and the column number after the file name in the alarm information, may be filtered out in the feature extraction (the reason why the row number and the column number are not considered is that the row number or the column number may change when the corresponding file is modified, but this does not affect the consistency of the codes), when the first alarm information and the second alarm information are different only in the row number and the column number, the feature of the first alarm information is also the same as the feature of the second alarm information.
Therefore, comparing the characteristic of the first alarm information with the characteristic of the second alarm information means comparing the first alarm information with the second alarm information, and finding out the characteristic of the second alarm information means finding out the second alarm information.
In step S300, for each feature of the second warning information, it is checked whether the feature exists in the feature set, and if not, the feature is determined to be a target feature.
When traversing every second alarm information in local _ warning.txt, every feature is extracted, whether the feature exists in the feature set or not is judged, if not, the second alarm information corresponding to the target feature is new alarm information introduced by modifying the first source code, the feature is determined as the target feature, and if so, the second alarm information corresponding to the target feature is the existing alarm information of the first source code, and the feature is not the target feature.
In other words, the target feature is different from the features in the feature set, and the second alarm information corresponding to the target feature is new alarm information introduced by modifying the first source code.
All target features can be found in the above manner. The second alarm information corresponding to each target feature in the local _ warning.txt may be saved in a local file, such as the local _ warning _ new.txt.
In step S400, second warning information corresponding to each target feature is output.
All the second alarm information in the local _ warning _ new.txt can be output, for example, for display, so that a developer can know all new alarm information introduced by modifying the first source code at this time, and then further judge whether the new alarm information needs to be eliminated, and if necessary, the developer can position the code with the problem in the code file according to the new alarm information for modification.
Optionally, when the target feature is not found or it is determined that the warning information corresponding to the target feature does not need to be eliminated, the method further includes: and uploading the feature sets of the second source code and the second alarm information to a code server so that the code server correspondingly stores the feature sets of the second source code and the second alarm information. Namely, the source code of the new version is released, and the feature set corresponding to the source code is stored at the same time, so that the source code is modified, compiled and debugged next time.
In the embodiment of the invention, after the source code is modified, the feature set formed by the features of all the first alarm information generated when the source code before modification is compiled is obtained, and the new alarm information introduced by the modification is found by comparing the features of the second alarm information generated when the modified source code is compiled with the feature set without manually finding out the new alarm information, so that the time consumption for determining the new alarm information is shortened, the workload of developers is reduced, and the inaccuracy caused by manually checking the alarm information is avoided.
In one embodiment, the step S200 of determining the characteristics of each second alarm message generated when the second source code is compiled includes the following steps:
s201: and for each second alarm message, extracting the file name to be alarmed, the code information to be alarmed and the alarm reason information from the second alarm message, and taking the extracted file name, code information and alarm reason information as the characteristics of the second alarm message.
The code information may include the code statement to be alerted (i.e., the code statement in which the problem occurred), for example, a second alert information is as follows:
test.c:6:10:warning:unused variable‘x’[-Wunused-variable]
int x
^
the file name "test.c", the code statement "int x", and the alarm cause information "unused variable 'x'" may be extracted as the feature of the second alarm information. That is, the above-mentioned second warning information has the features (abbreviated as feature a2) of "test.c", "int x", "unused variable 'x'".
The comparison shows that the feature a1 is the same as the feature a2, so that the feature a2 is not the target feature, and the second alarm information corresponding to the feature a2 is the existing alarm information.
In one embodiment, in step S201, extracting code information from the second warning information includes:
checking whether the alarm reason information in the second alarm information represents a redefined identifier;
if yes, extracting an identifier from the second alarm information, and taking the extracted identifier as code information;
and if not, extracting a code statement from the second alarm information, and taking the extracted code statement as code information.
Since there are various types of alarm information, the first to third alarm causes in the foregoing embodiments are not redefined identifiers, and only a code statement that suggests an alarm in the alarm information may be extracted as the code information.
However, the reason for the alarm of one piece of alarm information is to redefine the identifier as follows:
test.c:8:0:warning:"A_LEN"redefined
#define A_LEN 15
^
test.c:5:0:note:this is the location of the previous definition
#define A_LEN 10
^
here, two code statements to be alerted are prompted, which are "# define a _ LEN 15" and "# define a _ LEN 10", respectively, and at this time, a redefined identifier may be extracted as code information, for example, "a _ LEN" as code information.
It is possible to check whether "redefined" exists in the alarm reason information of the second alarm information to determine whether the alarm reason information represents a redefined identifier. The identifier may include a function name, a variable name, a constant name, etc., as long as it is a possible redefined symbol.
In one embodiment, the features include: the file name of the alarmed file, the code information of the alarmed file and the reason information of the alarm, wherein the code information comprises an identifier or a code statement;
in step S300, checking whether the feature exists in the feature set may include the following steps:
s301: checking whether a first feature containing a file name in the feature exists in the feature set;
s302: if yes, determining whether the feature exists in the feature set according to code information and alarm reason information contained in the feature;
s303: if not, determining that the feature does not exist in the feature set.
Different code files may always have functions with repeated naming (e.g. funcA { } is defined in a.c and b.c), variables, etc., and alarm reason information in different functions may also be repeated (e.g. useless variable intx is defined in funcA and funcB). When checking whether the feature exists in the feature set, if whether the code information or the alarm reason information in the feature exists in the feature set is checked first, whether the file names are the same or not is checked finally.
In this embodiment, whether a file name included in the feature exists in the feature set is preferentially checked, and when the first feature including the file name in the feature does not exist in the feature set, it may be directly determined that the feature does not exist in the feature set, and the code information of the feature and the alarm reason information may not be compared, and the next feature may be continuously determined, so that the determination efficiency of the target feature may be improved.
And when the first feature containing the file name in the feature exists in the feature set, determining whether the feature exists in the feature set according to the code information and the alarm reason information contained in the feature.
In one embodiment, the step S302 of determining whether the feature exists in the feature set according to the code information and the alarm reason information included in the feature includes:
s3021: checking whether at least one target first feature containing code information in the feature exists in all the first features;
s3022: if yes, determining that the feature exists in the feature set when the alarm reason information in any one target first feature is the same as the alarm reason information in the feature; when the alarm reason information in all the target first characteristics is different from the alarm reason information in the characteristics, determining that the characteristics do not exist in the characteristic set;
s3023: if not, determining that the feature does not exist in the feature set.
The alarm reason information in different functions may also be repeated (e.g. useless variable int x is defined in funcA and funcB), and if the alarm reason information in the feature exists in the feature set, it is finally still required to check whether the code information is the same.
In this embodiment, it is preferable whether at least one target first feature including the code information in the feature exists in all the first features, and when the target first feature including the code information in the feature does not exist in all the first features, it may be directly determined that the feature does not exist in the feature set, and the feature alarm cause information may continue to determine the next feature without performing comparison, so that the determination efficiency of the target feature may be further improved.
If the target first characteristics containing the code information in the characteristics exist in all the first characteristics, determining that the characteristics exist in the characteristic set when the alarm reason information in any one target first characteristic is the same as the alarm reason information in the characteristics; and when the alarm reason information in all the target first characteristics is different from the alarm reason information in the characteristics, determining that the characteristics do not exist in the characteristic set.
In this way, at least one of the file name, the code information and the alarm reason information of the found target feature is different from all the features in the feature set.
The following explains the compiling alarm processing method by a specific example:
suppose that: the code server manages a code base, and three code files of source codes exist in the code base: code _ a.c, code _ b.c, code _ c.c, three c files will generate 25 pieces of alarm information when compiled, wherein code _ a.c files generate 10 pieces of alarm information, code _ b.c generates 10 pieces of alarm information, and code _ c.c generates 5 pieces of alarm information.
The characteristics of each of the 25 alarm messages are stored in a file warning _ b.txt, as shown in the following table (1):
watch (1)
The developer downloads three code files, code _ a.c, code _ b.c and code _ c.c, and corresponding warning _ b.txt from the code server, saves the three code files and the corresponding warning _ b.txt in the electronic equipment, and modifies the codes.
In which only code _ c.c is modified, for example, a new variable int x is defined in function func20, and no other modification is made (the variable is not used). Therefore, when the code _ c.c file is compiled, an alert message B1 is generated like the following:
In function‘func20`:
Code_c.c:7:9:warning:unused variable‘x’[-Wunused-variable]
int x；
^
since there are 25 alarm messages in the three code files, the developer will generate 26 alarm messages when locally compiling the three code files of the source code, and only one of them is the newly added alarm message B1.
When confirming whether alarm information is introduced into all the alarm information, developers are conventionally required to check 26 pieces of alarm information one by one to confirm which piece of alarm information is introduced by newly modified code. When no alarm information is introduced, the old alarm information needs to be traversed once to confirm whether new alarm information is introduced. More workload is caused to developers, and new alarm information is easy to miss when the number of the old alarm information is large.
In the embodiment of the invention, a developer can store 26 pieces of generated alarm information into local _ warning.txt when compiling three code files of a source code.
When the compiling is completed, the alarm information in the local _ warning.txt can be read one by one, the characteristics of the alarm information are extracted, the characteristics of the alarm information are matched with the characteristics of the old alarm information in the warning _ b.txt, if the characteristics of the alarm information are not found in the warning _ b.txt, the alarm information is considered as new alarm information and is recorded in the local _ warning _ new.txt, otherwise, the alarm information is considered as the old alarm information.
And after all the alarm information in the local _ warning.txt is traversed, all the alarm information in the warning _ local _ new.txt file is output to be displayed. Therefore, the developer can visually see the alarm information introduced by the modification, in this example, only one new alarm information introduced by code _ c.c, namely alarm information B1, is output, and the whole process does not need to be checked manually by the developer.
The present invention also provides a compiling alarm processing device, and referring to fig. 2, the compiling alarm processing device 100 includes:
a feature set obtaining module 101, configured to obtain a feature set, where the feature set includes a feature of each first alarm information generated when the first source code is compiled;
the characteristic determining module 102 is configured to determine a characteristic of each second alarm message generated when a second source code is compiled, where the second source code is a modified source code of the first source code;
a target characteristic determining module 103, configured to check, for a characteristic of each second alarm information, whether the characteristic exists in the characteristic set, and if not, determine that the characteristic is a target characteristic;
and the alarm information output module 104 is configured to output second alarm information corresponding to each target feature.
In one embodiment of the present invention,
the features at least include: code information to be alerted;
when the characteristic determining module determines the characteristic of each second alarm information generated when the second source code is compiled, the characteristic determining module is specifically configured to:
and for each second alarm message, extracting the file name to be alarmed, the code information to be alarmed and the alarm reason information from the second alarm message, and taking the extracted file name, code information and alarm reason information as the characteristics of the second alarm message.
In one embodiment, when the feature determining module extracts the code information from the second warning information, the feature determining module is specifically configured to:
checking whether the alarm reason information in the second alarm information represents a redefined identifier;
if yes, extracting an identifier from the second alarm information, and taking the extracted identifier as code information;
and if not, extracting a code statement from the second alarm information, and taking the extracted code statement as code information.
In one embodiment of the present invention,
the features include: the file name of the alarmed file, the code information of the alarmed file and the reason information of the alarm, wherein the code information comprises an identifier or a code statement;
when the target feature determining module checks whether the feature exists in the feature set, the target feature determining module is specifically configured to:
checking whether a first feature containing a file name in the feature exists in the feature set;
if yes, determining whether the feature exists in the feature set according to code information and alarm reason information contained in the feature;
if not, determining that the feature does not exist in the feature set.
In one embodiment, when the target feature determining module determines whether the feature exists in the feature set according to the code information and the alarm reason information included in the feature, the target feature determining module is specifically configured to:
checking whether at least one target first feature containing code information in the feature exists in all the first features;
if yes, determining that the feature exists in the feature set when the alarm reason information in any one target first feature is the same as the alarm reason information in the feature; when the alarm reason information in all the target first characteristics is different from the alarm reason information in the characteristics, determining that the characteristics do not exist in the characteristic set;
if not, determining that the feature does not exist in the feature set.
The implementation process of the functions and actions of each unit in the above device is specifically described in the implementation process of the corresponding step in the above method, and is not described herein again.
For the device embodiments, since they substantially correspond to the method embodiments, reference may be made to the partial description of the method embodiments for relevant points. The above-described embodiments of the apparatus are merely illustrative, wherein the units described as separate parts may or may not be physically separate, and the parts shown as units may or may not be physical units.
The invention also provides an electronic device, which comprises a processor and a memory; the memory stores a program that can be called by the processor; when the processor executes the program, the compiling alarm processing method according to the foregoing embodiment is implemented.
The embodiment of the compiling alarm processing device can be applied to electronic equipment. Taking a software implementation as an example, as a logical device, the device is formed by reading, by a processor of the electronic device where the device is located, a corresponding computer program instruction in the nonvolatile memory into the memory for operation. From a hardware aspect, as shown in fig. 3, fig. 3 is a hardware structure diagram of an electronic device where the compiling alarm processing apparatus 100 is located according to an exemplary embodiment of the present invention, and except for the processor 510, the memory 530, the interface 520, and the nonvolatile memory 540 shown in fig. 3, the electronic device where the apparatus 100 is located in the embodiment may also include other hardware generally according to the actual function of the electronic device, which is not described again.
The present invention also provides a machine-readable storage medium on which a program is stored, which, when executed by a processor, implements the compiling alarm processing method according to the foregoing embodiment.
The present invention may take the form of a computer program product embodied on one or more storage media including, but not limited to, disk storage, CD-ROM, optical storage, and the like, having program code embodied therein. Machine-readable storage media include both permanent and non-permanent, removable and non-removable media, and the storage of information may be accomplished by any method or technology. The information may be computer readable instructions, data structures, modules of a program, or other data. Examples of machine-readable storage media include, but are not limited to: phase change memory (PRAM), Static Random Access Memory (SRAM), Dynamic Random Access Memory (DRAM), other types of Random Access Memory (RAM), Read Only Memory (ROM), Electrically Erasable Programmable Read Only Memory (EEPROM), flash memory or other memory technologies, compact disc read only memory (CD-ROM), Digital Versatile Discs (DVD) or other optical storage, magnetic tape storage or other magnetic storage devices, or any other non-transmission medium, may be used to store information that may be accessed by a computing device.
The above description is only for the purpose of illustrating the preferred embodiments of the present invention and is not to be construed as limiting the invention, and any modifications, equivalents, improvements and the like made within the spirit and principle of the present invention should be included in the scope of the present invention.
Claims (10)
1. A compilation alarm processing method, comprising:
acquiring a feature set, wherein the feature set comprises the features of each first alarm message generated when a first source code is compiled;
determining the characteristics of each second alarm message generated when a second source code is compiled, wherein the second source code is the modified source code of the first source code;
for the characteristic of each second alarm message, checking whether the characteristic exists in the characteristic set, and if not, determining that the characteristic is a target characteristic;
and outputting second alarm information corresponding to each target characteristic.
2. The compiled alarm processing method of claim 1, wherein determining the characteristics of each second alarm message generated when the second source code is compiled, comprises:
and for each second alarm message, extracting the file name to be alarmed, the code information to be alarmed and the alarm reason information from the second alarm message, and taking the extracted file name, code information and alarm reason information as the characteristics of the second alarm message.
3. The compiling alarm processing method of claim 2, wherein extracting code information from the second alarm information comprises:
checking whether the alarm reason information in the second alarm information represents a redefined identifier;
if yes, extracting an identifier from the second alarm information, and taking the extracted identifier as code information;
and if not, extracting a code statement from the second alarm information, and taking the extracted code statement as code information.
4. The compiled alarm processing method of claim 1,
the features include: the file name of the alarmed file, the code information of the alarmed file and the reason information of the alarm, wherein the code information comprises an identifier or a code statement;
checking whether the feature exists in the feature set, including:
checking whether a first feature containing a file name in the feature exists in the feature set;
if yes, determining whether the feature exists in the feature set according to code information and alarm reason information contained in the feature;
if not, determining that the feature does not exist in the feature set.
5. The compiling alarm processing method of claim 4 wherein determining whether the feature exists in the feature set based on code information and alarm cause information included in the feature comprises:
checking whether at least one target first feature containing code information in the feature exists in all the first features;
if yes, determining that the feature exists in the feature set when the alarm reason information in any one target first feature is the same as the alarm reason information in the feature; when the alarm reason information in all the target first characteristics is different from the alarm reason information in the characteristics, determining that the characteristics do not exist in the characteristic set;
if not, determining that the feature does not exist in the feature set.
6. A compilation alarm processing apparatus, comprising:
the characteristic set acquisition module is used for acquiring a characteristic set, wherein the characteristic set comprises the characteristics of each first alarm message generated when the first source code is compiled;
the characteristic determining module is used for determining the characteristic of each second alarm message generated when a second source code is compiled, wherein the second source code is the modified source code of the first source code;
the target characteristic determining module is used for checking whether the characteristic exists in the characteristic set or not aiming at the characteristic of each second alarm message, and if not, determining that the characteristic is the target characteristic;
and the alarm information output module is used for outputting second alarm information corresponding to each target characteristic.
7. The compilation alarm processing apparatus of claim 6,
the features at least include: code information to be alerted;
when the characteristic determining module determines the characteristic of each second alarm information generated when the second source code is compiled, the characteristic determining module is specifically configured to:
and for each second alarm message, extracting the file name to be alarmed, the code information to be alarmed and the alarm reason information from the second alarm message, and taking the extracted file name, code information and alarm reason information as the characteristics of the second alarm message.
8. The compiling alarm processing device of claim 7, wherein the characteristic determining module, when extracting the code information from the second alarm information, is specifically configured to:
checking whether the alarm reason information in the second alarm information represents a redefined identifier;
if yes, extracting an identifier from the second alarm information, and taking the extracted identifier as code information;
and if not, extracting a code statement from the second alarm information, and taking the extracted code statement as code information.
9. The compilation alarm processing apparatus of claim 6,
the features include: the file name of the alarmed file, the code information of the alarmed file and the reason information of the alarm, wherein the code information comprises an identifier or a code statement;
when the target feature determining module checks whether the feature exists in the feature set, the target feature determining module is specifically configured to:
checking whether a first feature containing a file name in the feature exists in the feature set;
if yes, determining whether the feature exists in the feature set according to code information and alarm reason information contained in the feature;
if not, determining that the feature does not exist in the feature set.
10. The compiling alarm processing device of claim 9 wherein the target feature determining module, when determining whether the feature exists in the feature set according to the code information and the alarm reason information included in the feature, is specifically configured to:
checking whether at least one target first feature containing code information in the feature exists in all the first features;
if yes, determining that the feature exists in the feature set when the alarm reason information in any one target first feature is the same as the alarm reason information in the feature; when the alarm reason information in all the target first characteristics is different from the alarm reason information in the characteristics, determining that the characteristics do not exist in the characteristic set;
if not, determining that the feature does not exist in the feature set.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN201911315930.5A CN111158694A (en) | 2019-12-19 | 2019-12-19 | Compiling alarm processing method and device |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN201911315930.5A CN111158694A (en) | 2019-12-19 | 2019-12-19 | Compiling alarm processing method and device |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| CN111158694A true CN111158694A (en) | 2020-05-15 |
Family
ID=70557380
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN201911315930.5A Pending CN111158694A (en) | 2019-12-19 | 2019-12-19 | Compiling alarm processing method and device |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN111158694A (en) |
Citations (6)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US20080052695A1 (en) * | 2006-08-22 | 2008-02-28 | Marc A Dickenson | Method and system for compilation error isolation, optimization and resolution |
| CN105446723A (en) * | 2014-09-02 | 2016-03-30 | 国际商业机器公司 | Method and device for identifying semantic difference between source code versions |
| CN105549959A (en) * | 2015-12-04 | 2016-05-04 | 小米科技有限责任公司 | Compiling inspection method and device |
| US20160306612A1 (en) * | 2015-04-14 | 2016-10-20 | International Business Machines Corporation | Determining errors and warnings corresponding to a source code revision |
| CN106909500A (en) * | 2015-12-23 | 2017-06-30 | 黄正兰 | The detection method and system of mistake are introduced in Airborne Software development process |
| CN107291428A (en) * | 2016-03-31 | 2017-10-24 | 晨星半导体股份有限公司 | Source code error detecting device and debugging method |
-
2019
- 2019-12-19 CN CN201911315930.5A patent/CN111158694A/en active Pending
Patent Citations (6)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US20080052695A1 (en) * | 2006-08-22 | 2008-02-28 | Marc A Dickenson | Method and system for compilation error isolation, optimization and resolution |
| CN105446723A (en) * | 2014-09-02 | 2016-03-30 | 国际商业机器公司 | Method and device for identifying semantic difference between source code versions |
| US20160306612A1 (en) * | 2015-04-14 | 2016-10-20 | International Business Machines Corporation | Determining errors and warnings corresponding to a source code revision |
| CN105549959A (en) * | 2015-12-04 | 2016-05-04 | 小米科技有限责任公司 | Compiling inspection method and device |
| CN106909500A (en) * | 2015-12-23 | 2017-06-30 | 黄正兰 | The detection method and system of mistake are introduced in Airborne Software development process |
| CN107291428A (en) * | 2016-03-31 | 2017-10-24 | 晨星半导体股份有限公司 | Source code error detecting device and debugging method |
Non-Patent Citations (1)
| Title |
|---|
| 牛霜霞;吕卓;张威;莫坚松;: "改进的基于代码污染识别安全警告的算法" * |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| US7353427B2 (en) | Method and apparatus for breakpoint analysis of computer programming code using unexpected code path conditions | |
| US9898387B2 (en) | Development tools for logging and analyzing software bugs | |
| CN110554965B (en) | Automated fuzz testing method, related equipment and computer readable storage medium | |
| US9098500B1 (en) | Revision history storage and maintenance | |
| CN112764753A (en) | Project deployment method and device, electronic equipment and storage medium | |
| US20230259339A1 (en) | Multi-Platform Compiling | |
| CN113742215B (en) | Method and system for automatically configuring and calling test tool to perform test analysis | |
| CN113094252B (en) | Test case generation method and device, computer equipment and storage medium | |
| US20100313186A1 (en) | Developer-managed debugger data records | |
| CN112000367B (en) | Binary library file version compatibility identification method and device | |
| CN117331539A (en) | Method and device for continuous integration, electronic equipment and readable storage medium | |
| US20020129336A1 (en) | Automatic symbol table selection in a multi-cell environment | |
| CN111158694A (en) | Compiling alarm processing method and device | |
| CN111930387B (en) | Integration method and device of integration package, electronic equipment and storage medium | |
| CN114817047A (en) | Compiler test method, case generation method and device and instruction storage structure | |
| US8010572B1 (en) | Kstore scenario simulator processor and XML file | |
| US11100131B2 (en) | Simulation of a synchronization of records | |
| CN115858012B (en) | Program variable configuration method, device, electronic equipment and storage medium | |
| CN116243971B (en) | Static dependency bootstrapping-based kernel-independent module construction method | |
| CN112860285B (en) | SP upgrade package generation method and device of financial self-service equipment and computer equipment | |
| Hewardt et al. | Advanced windows debugging | |
| CN117687913A (en) | Distributed transaction testing method and device, electronic equipment and storage medium | |
| JP6888336B2 (en) | Stub generators, methods, and programs | |
| CN112860284A (en) | SP upgrade package generation method and device for remote upgrade of equipment and computer equipment | |
| CN114064474A (en) | Test method, test device, electronic equipment and computer readable storage medium |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| PB01 | Publication | ||
| PB01 | Publication | ||
| SE01 | Entry into force of request for substantive examination | ||
| SE01 | Entry into force of request for substantive examination | ||
| RJ01 | Rejection of invention patent application after publication |
Application publication date: 20200515 |
|
| RJ01 | Rejection of invention patent application after publication |