Microchip Technology XC8 Standard Compiler (Workstation) SW006021-1 SW006021-1 ユーザーズマニュアル
製品コード
SW006021-1
How To’s
2012 Microchip Technology Inc.
DS52053B-page 67
3.7
FIXING CODE THAT DOES NOT WORK
This section examines issues relating to projects that do not build due to compiler
errors, or which build but do not work as expected.
errors, or which build but do not work as expected.
3.7.1
How Do I Find Out What an Warning/error Message Means?
Each warning or error message has a description, and possibly sample code that might
trigger such an error, listed in the messages chapter, see Appendix B. “Error and
Warning Messages”. The compiler prints with each message a unique ID number in
brackets. Use this number to look up the message in the manual. This number also
allows you to control message behavior using options and pragmas, see Section 4.6.5
“Changing Message Behavior”.
trigger such an error, listed in the messages chapter, see Appendix B. “Error and
Warning Messages”. The compiler prints with each message a unique ID number in
brackets. Use this number to look up the message in the manual. This number also
allows you to control message behavior using options and pragmas, see Section 4.6.5
“Changing Message Behavior”.
3.7.2
How Do I Find the Code that Caused Compiler Errors Or
Warnings in My Program?
Warnings in My Program?
In most instances, where the error is a syntax error relating to the source code, the
message produced by the compiler indicates the offending line of code, see
Section 4.6 “Compiler Messages”. If you are compiling in MPLAB IDE, then you can
double-click the message and have the editor take you to the offending line. But iden-
tifying the offending code is not always so easy.
message produced by the compiler indicates the offending line of code, see
Section 4.6 “Compiler Messages”. If you are compiling in MPLAB IDE, then you can
double-click the message and have the editor take you to the offending line. But iden-
tifying the offending code is not always so easy.
In some instances, the error is reported on the line of code following the line that needs
attention. This is because a C statement is allowed to extend over multiple lines of the
source file. It is possible that the compiler may not be able to determine that there is an
error until it has started to scan to statement following. So in the following code
attention. This is because a C statement is allowed to extend over multiple lines of the
source file. It is possible that the compiler may not be able to determine that there is an
error until it has started to scan to statement following. So in the following code
input = PORTB // oops - forgot the semicolon
if(input>6)
// ...
The missing semicolon on the assignment statement will be flagged on the following
line that contains the if() statement.
line that contains the if() statement.
In other cases, the error might come from the assembler, not the code generator. If the
assembly code was derived from a C source file then the compiler will try to indicate
the line in the C source file that corresponds to the assembly that is at fault. If the
source being compiled is an assembly module, the error directly indicates the line of
assembly that triggered the error. In either case, remember that the information in the
error relates to some problem is the assembly code, not the C code.
assembly code was derived from a C source file then the compiler will try to indicate
the line in the C source file that corresponds to the assembly that is at fault. If the
source being compiled is an assembly module, the error directly indicates the line of
assembly that triggered the error. In either case, remember that the information in the
error relates to some problem is the assembly code, not the C code.