Using the Xbase++ pre-processor for debugging syntax errors

I Love Xbase++ (ILX)
The portal for Xbase++ developers worldwide

Pat France

New member
Staff member
I am here to help you!
Aug 9, 2022
23
3
3
Customer Identifier
E114627
Sometimes, a syntax error may be reported when building your project whose root cause is not obvious. In the following example, the compiler detected a syntax error while processing the file test45.prg:

Code:
File: test45.prg Lines:    7
test45.prg(45:0): error XBT0200: Syntax Error
test45.prg(46:0): error XBT0250: Incomplete expression
2 error(s) found in file test45.prg!

The offending line is the following:

Xbase++:
45: PARAM->APPTYPE := "VIO"

Offhandedly, there seems to be nothing wrong with the code; a character value is assigned to an apptype field in the param table.

In order to find out what actually threw off the compiler, it often helps to take a look at the output generated by the pre-processor. Because commands may have been translated to function calls, defines replaced with their literal equivalent and so on, the code that actually is being compiled may look substantially different from the code seen in the editor. Normally, the pre-processor output is not accessible. However, the following command instructs the compiler to retain the pre-processor output after the compile run:

Code:
xpp /p test45.prg <ENTER>

This creates a file test45.ppo with the pre-processor output, and it can be opened to examine the input to the compiler. In the case of the above example, it was this (excerpt only):

Xbase++:
(...)
#line 1 "test45.prg"
#line 1 "appsettings.ch"@"appsettings.ch"
#line 1 "test45.prg"

(...)
  PARAM->"test" := 12
(...)

Aha! Apparently, the token "apptype" had been replaced with the string "test" prior to the actual compile run, resulting in illegal code. An examination of the .ch files included into test45.prg finally produced the following definition in appsettings.ch:

Xbase++:
// production = non-debug, optimized
// test       = debug with tracing enabled
#define APPTYPE "test"

Apparently, a new #define had been added recently which happens to match the field name used when accessing the table. This problem wasn't visible in the source code, but was introduced during the pre-processing phase. Examining the resulting output can often help in pinpointing problems such as the one outlined above.

Note:
Remember that defines are case sensitive, thats why all defines shall be upper case. And all variables shall use hungarian notations as well as all field and alias names shall be lower case. The later makes your ISAM or SQL command even better readable. By following these rules issues like outlined above can not occur.
 
Last edited by a moderator: