Function used but not defined - numeric values in error msg

[benoitstjean]

Compiler: 5.026
Device: PIC24EP512GP806

I know this is a very trivial question and I usually know exactly the cause but this time, for the life of me, I can't find the problem.

However, regardless, what I definitely want to know once and for all are what the values mean in the error message:

*** ERROR 112 "C:\{file path\name.h}" Line 959(1,1): Function used but not defined: ... [function name] 1861 SCR=12293

So, first-off, line 959 is in a .h file which does not even have any relation to the actual function indicated in the error message. That's one issue with the compiler... pointing to some random line. But, what does the 1861 and 12293 values mean?

Thanks,

Ben

[jeremiah]

I don't know what the numbers mean, but:

It would be helpful if you could post the section of code it points to (along with some before/after code for context) to see.

It could be that you have a typo in a previous line and that makes a part of your code look like a function call to your compiler and that line happens to be the one that it ends on when it makes that decision.

You probably already know this, but "function used but not defined" usually indicates you have a function defined below where it is used or not defined at all.

Example:

[benoitstjean]

Hi Jeremiah,

I found the problem. As I mentioned, I know that this problem is usually quite simple and fair enough, I had a typo! :)

But, it would still be nice to know what those values mean just in case they point to something?

Anyhow, it's really no big deal but it would just be nice if the error messages would be explicit and point directly to the actual error and not just some random line number.

Thanks!

Ben

[jeremiah]

It's not as random as you think. If you ever get a chance to, take some time to look up a tutorial on writing a basic compiler parser. The document "Let's Build a Compiler" by Jack Crenshaw is a good down to earth one that I recommend.

If you can wrap your head around how a compiler actually reads the file, then some things like this actually make a lot more sense, and it will make you better at diagnosing really weird errors.

Also consider that it's easier for the coder to kind of "arm chair captain" the compilation process and note how a compiler should be able to see something, but we look at code with a bias of knowing the intent (or possible intent) and the various patterns. The compiler has a ruleset to follow and a particular algorithm to read the file to compare it to that ruleset. It knows nothing of intent or patterns. It doesn't know that a particular typo when fixed would change the code one way or the other, so all it can do is report it relative to its algorithm.

Some compilers have gotten better about this as they have grown (GCC is much better than it used to be as is Visual Studio's compiler). But there are limits that are more based around the implementation.