In the previous post we learnt about the data types in MSX-C and how important it is to use the right one in order to keep our programs free of bugs. However, when bugs happen it’s not always easy to track them down and fix them, so it would be nice to have a tool to help with this. MSX-C’s Type Parameter Checker (FPC.COM) is such a tool. We already saw it back in chapter #14, but we talked mostly about ist command line parameters. Today we’re going to actually see how it works and use it to locate bugs in our programs.

Data type integrity checks

MSX-C is very strict about the types of the parameters passed to functions. Using the wrong type (for example, passing a char to a function that expects an int) will result in the function not receiving the right data. The reason for this is that depending on the type of the data the parameters will be passed in one CPU register or another. The full details are in chapter #23, though that was a very technical post. You don’t need to worry about this mechanism for now.

In any case, the MSX-C compiler doesn’t perform any kind of type checking during compilation. The reason is that in this version of the C language function declarations don’t include information about the function arguments.

Because of this, sometimes we’ll successfully compile a program and everything will look fine until we actually run it and notice that it doesn’t work as we expected. This is often true with programs ported to MSX-C from other platforms, because other C compilers treat the types int and char in almost the same way.

This is where FPC.COM comes in. This support tool compares the function calls in our programs with the actual function definition and is able to warn us when the function arguments aren’t correct.

Let’s see an example of how to use FPC.COM to check a program that contains bugs. Open the text editor and type the program below. It is supposed to print the letters A through Z on the screen, and compiling it manually works just fine (no errors):

Compiling, linking and assembling ABCDE.COM (Click to enlarge)

However, if you try and run the program you’ll notice that it doesn’t work as expected. It exits without printing anything on the screen, or just printing garbage (depending on the contents of the memory at that moment).

This is the kind of situation where FPC.COM helps. FPC uses the .TCO file generated by CF.COM as input, so it only makes sense to run it after CF:

(Click to enlarge)

At this point we can run FPC with the program name as parameter, together with the TCO files of the MSX-C libraries:

• LIB for the standard library
• GLIB for the MSX-C Library graphics library

There are more TCO files (remember that we installed them in A:\UTILS), but we haven’t learnt what those are yet, so we’ll ignore them for now. Enter the command line like this:

FPC abcde lib glib

The first parameter is the file name of the program we want to check, and the remaining parameters are all the file names of the library files to compare it with. If there are no errors then FPC will just print the message “complete” on the screen and exit, but if it finds any problems then it will print the file name and function where the bug happens:

(Click to enlarge)

In this case FPC is telling us that inside the file ABCDE.TCO, in the main() function we’re calling putchar() with the wrong type in the first argument. As we saw in the previous post, the expression ‘A’ + i is not a char, but an int. To fix the problem we just need to cast the expression to a char and compile, and this time the program runs fine:

(Click to enlarge)

Other errors detected by FPC

When FPC finds a problem in the code it prints an error message in this format:

• First, the file name where the problem happens. Until now we’ve only seen programs that are contained in a single file, but later when we see how to compile per parts this will be very useful.
• Second, the function name where the problem was found.
• Third, the function call that contains the error
• And fourth, the description of the problem.

(Click to enlarge)

There are three kinds of errors that FPC can detect:

“… : conflicting number of arguments”

This happens whenever we’re calling a function with the wrong number or arguments. For example, calling putchar() with two parameters.

Note that some functions such as printf() take a variable number of arguments. FPC doesn’t check those.

“…: nth argument conflict”

This is the case we saw earlier in this post. It happens when the types of the arguments in a function call don’t match the types the function expects.

As before, remember that FPC will not check functions that take variable arguments.

“…: undefined”

This happens when FPC can’t find a function name in the libraries. This can be because the function name isn’t spelt correctly in the code, or because we forgot to add the library file to the FPC command line.

Integrating FPC into the build process

If you’re using the compile script that we created in chapter #12 then you’re all good. That script already runs FPC right after CF:

(Click to enlarge)

If you’re compiling manually, or you wrote your own script, then make sure to run FPC after CF. FPC needs the TCO file that CF creates.

Summary

This time we’ve zoomed into FPC. We’ve learnt how to use it to detect type and argument errors in function calls.

In the next post…

The next three or four posts will be about screen output. We’ll start with a much more detailed view of the printf() function. After that we’ll learn about control codes and escape sequences that handle the display of text on the screen.

This series of articles is supported by your donations. If you’re willing and able to donate, please visit the link below to register a small pledge. Every little amount helps.

Javi Lavandeira’s Patreon page