Error and Warning Messages

• ``syntax error''
  
  This is the granddaddy of all compiler error messages, although it can be less than useful. It means that there's something wrong with the syntax of your program (yes, I know, you figured that much out already). Roughly speaking, ``syntax'' refers to the typographical characters you've used to express your program and the order you've arranged them in. If parts of your program are in the wrong order, or if some required punctuation (such as a comma, semicolon, brace, or parenthesis) is missing, you're liable to get this error. The actual error is not always on the line the compiler indicates; sometimes, a problem on one line isn't noticed right away but percolates down and triggers an error message a few lines later.
  
  You may also get this error if you're trying to use an old, pre-ANSI compiler (such as cc on many Unix systems) to compile a newer, ANSI-compatible program. (Try using acc or gcc instead.)
• ``undefined symbol x''
• ``undeclared variable x''
• ``x undefined''
  
  All of these mean that you have apparently tried to use a variable named x (or, of course, whatever name the compiler is complaining about) without declaring it. C requires that all variables be declared before use; the declaration informs the compiler in advance of the name and type of each variable that you will be using. (If the compiler is complaining about a variable which you did think you'd declared, it may be that you misspelled it either where you declared it or where you used it, or that you declared it in a different part of your program than the part where you're trying to use it.)
  
  (See also discussion about ``undefined external'' message below.)
• ``newline in string or character constant''
  
  This simply means that you've got an unbalanced single quote ' or double quote ". Here is an example:

  	printf("hello, world!\n);
  

  You might wonder why it's illegal to have a newline in a string constant (and why it is that you have to use the \n sequence instead). The reason is precisely so that the compiler can give you this error message when you accidentally leave out a closing quote. Otherwise, the compiler might try to interpret the whole rest of your source file as one very long string constant.
• ``bad lvalue'' (or ``missing lvalue'')
  
  lvalue is a piece of compiler writer's jargon which refers to an object with a location. (Actually, its original derivation had to do with the fact that lvalues are what appear on the left hand side of an assignment operator.) What this message means to you and me is that the compiler was trying to assign to or modify some variable, but there was no variable there for it to modify (or, perhaps, for some reason the particular variable could not be modified). For example, if you accidentally wrote

  	1 = a + b
  

  (that's a number 1 there, not a letter l), the compiler would complain, because the number 1 is not a variable which it's possible for you to assign a new value to.
• ``can't find header file xxx.h''
  
  This message means that one of your source files contains a line like

  	#include <xxx.h>
  

  or

  	#include "xxx.h"
  

  but the compiler (specifically, the preprocessor) could not find the header file xxx.h.
  
  If the header file is one of your own (usually one that you've used the #include "" form with), make sure that you have actually composed (written) the header file, and that it is in the correct directory--usually, the same directory as the rest of your source files.
  
  If the header file is a Standard one (usually one that you've used the #include <> form with), such as stdio.h, then there's something wrong with the way the compiler has been installed or configured. You may have to go into a configuration screen and set the directory name where the standard header files are kept. (Of course, to do this, you will have to know where that directory is! It usually has a name like ``include'', and is located somewhere within the compiler's installation tree.)
  
  (Finally, if the preprocessor is complaining about a misspelled header name, simply fix the misspelling.)
• ``undefined external: xxx''
  
  This message means that during the linking stage, a function (or, occasionally, a global variable) by the name of xxx could not be found. There can be several causes, depending on whether the function is one of your own, or was one which you had expected would be provided for you.
  
  If the function name is one of your own, you'll have to figure out why the linker couldn't find it. Did you provide a defining instance (not just an external declaration) for the function? Did you enter its source code into the same file(s) as the rest of the program? If not, did you tell the linker where to find it? You'll either have to write the function if you forgot to, or adjust the program's build procedure (perhaps by editing the ``Makefile'' or adding a ``module'' to the ``project list'').
  
  If the function name is one from the Standard C library, such as printf, which was supposed to be provided for you, you'll have to figure out why the linker couldn't find it. Occasionally, the problem is that the compiler doesn't know where the Standard library is. You may have to go into a configuration screen and set the path or directory name of the library. (Of course, to do this, you will have to know where the library is! It usually has a name containing the string ``libc'', such as libc.a or SLIBC.LIB. The libraries--there may be several--are often located in a subdirectory named ``lib'', somewhere within the compiler's installation tree.)
  
  If the undefined function's name is close but not exactly the same as one of your own functions or one of the Standard library functions, it obviously means that you've mistyped its name in a function call somewhere. All you have to do is find that typo in whichever source file it's in, fix it, and recompile.
  
  If the function is a math-related one, such as sin, cos, or sqrt, and you're using a Unix system, make sure that you've used the -lm option, at the end of the command line, when compiling/linking.
  
  If the function name printed in the error message includes a leading underscore, don't worry about the underscore. (Under some compilers, the names manipulated by the linker have this underscore added by the compiler, although you continue to refer to the function by the name you thought you had given it.) In most cases, if the linker complains about ``_myfunc'' being undefined, it's ``myfunc'' you've got to worry about.
  
  If the name is ``_end'', you'll rarely have to worry about it; this is a symbol used internally by the traditional Unix linkers, and shows up as ``undefined'' only when there are also other symbols undefined. If you fix all of the others, the mysterious undefined ``_end'' will also disappear.
  
  (See also discussion about ``undeclared variable'' message above.)
• ``call of function with no prototype in scope''
  
  This message means that the compiler has noticed you trying to call a function which the compiler has no (or only minimal) information about. Under most compilers, this is a warning message, not an error, because the compiler is willing to assume certain things about unknown functions, and will let you try to call them. However, the assumptions it makes might not be right, and the compiler won't be able to check that you've called the function with the correct number and type of arguments, which is why it issues the warning.
  
  If you'd like the compiler to keep checking function calls carefully for you, you must arrange to supply prototypes for the functions you call. For functions from the Standard C library, you almost always supply prototypes by using the #include directive. For example, in a source file where you call printf, you should always have the line

  	#include <stdio.h>
  

  near the top of the file, because <stdio.h> contains the prototype for printf (and many other functions). For your own functions, you will have to supply your own prototypes. (You may wish to place them in your own header files, and use #include "" to bring them in wherever they're needed. Using header files in this way is generally more reliable than manually typing copies of the prototype into each source file where a particular function of yours is called.)
  
  If, for whatever reason, you'd rather that the compiler not check function calls for you (that is, if you think that you can get them right yourself), you can usually configure a compiler not to complain about function calls with no prototype in scope.

top