Author Topic: Trying to debug preprocess() (since version 10.0)  (Read 5508 times)

cappy2112

  • Community Member
  • Posts: 91
  • Hero Points: 0
Trying to debug preprocess() (since version 10.0)
« on: July 24, 2007, 12:39:41 AM »
I have been trying to get the preprocess() function to work, since version 10.0.

Now using 12.02 I'm still having problems getting it working, as well as trying to understand why it is performing the way it is.

In the C project I'm trying to preprocess, I have to parse our header files externally from Slick.
The program that parses the header files also dynamically generates a Slick macro, which contains
a call to preprocess(), with a huge string of symbol definitions as the argument to preprocess().

In another Slick Macro, I then iterate over all the open files/buffers, using args in the call to preprocess() to define/undefine the symbols.

Most of the C files are preprocessed ok (I haven't checked every line in every file).

But for some reason, at least one header file is not preprocessed correctly.

So I've eliminated all of the steps of parsing the headers externally to slick, and pasted a simple call to preprocess() on the slick command line, with only a few symbols.

I do this while the header file in question is "selected", and again, preprocess() does not fold the lines I expect.

This is a subsection of the header file having the problem

#if SWITCH_TYPE == ABC1234           
#define SYM_THIS_SYMBOL        FALSE   

#elif SWITCH_TYPE == DEF5432             
#define SYM_THIS_SYMBOL          TRUE
#endif

It's just simple C preprocessor directives.

The call on the Slick cmd line looks like this

preprocess  -w TRUE=1 FALSE=0  ABC1234=100u DEF5432=200u SWITCH_TYPE=ABC1234

When I change it to this

preprocess  -w TRUE=1 FALSE=0  ABC1234=100u DEF5432=200u SWITCH_TYPE=DEF5432

I would expect the logic to be reversed with the second call to preprocess, but the outcome is the same.

When I remove the -w in the call to preprocess, Slick complains that SWITCH_TYPE is not defined, as well as all of the other symbols in the call to preprocess()

Why is this SWITCH_TYPE not defined, when I explicitly define it on the command line?

Would someone shed some light on what I am doing incorrectly?

Thanks
« Last Edit: July 24, 2007, 12:46:38 AM by cappy2112 »

Lee

  • SlickEdit Team Member
  • Senior Community Member
  • *
  • Posts: 1299
  • Hero Points: 130
Re: Trying to debug preprocess() (since version 10.0)
« Reply #1 on: July 26, 2007, 02:00:00 PM »
It looks like somewhere in the expression evaluation, it doesn't recognize 100u or 200u as valid numbers, so it has to resort to the default value, which is 0 in this case.  So it's evaluating as SWITCH_TYPE = 0, ABC1234 = 0, and since 0 == 0, it happily goes on about it's business.  If you change the command to read:

preprocess  -w TRUE=1 FALSE=0  ABC1234=100 DEF5432=200 SWITCH_TYPE=ABC1234

-or-

preprocess  -w TRUE=1 FALSE=0  ABC1234=100 DEF5432=200 SWITCH_TYPE=DEF5432

it should work correctly.


I haven't fully traced all the code yet, but the expression evaluation uses the built-in function isnumber(_str number) for validation, and I'm betting it just doesn't handle or care about U or L or UL and returns false.

cappy2112

  • Community Member
  • Posts: 91
  • Hero Points: 0
Re: Trying to debug preprocess() (since version 10.0)
« Reply #2 on: July 26, 2007, 02:11:36 PM »
It looks like somewhere in the expression evaluation, it doesn't recognize 100u or 200u as valid numbers, so it has to resort to the default value, which is 0 in this case.  So it's evaluating as SWITCH_TYPE = 0, ABC1234 = 0, and since 0 == 0, it happily goes on about it's business.  If you change the command to read:

preprocess  -w TRUE=1 FALSE=0  ABC1234=100 DEF5432=200 SWITCH_TYPE=ABC1234

-or-

preprocess  -w TRUE=1 FALSE=0  ABC1234=100 DEF5432=200 SWITCH_TYPE=DEF5432

it should work correctly.


I haven't fully traced all the code yet, but the expression evaluation uses the built-in function isnumber(_str number) for validation, and I'm betting it just doesn't handle or care about U or L or UL and returns false.


Thanks Lee.
Unfortunately, I cannot remove the u L or UL from the source code it's preprocessing.
That's likely to cause problems when the code is compiled - or worse, at runtime.