Watcom preprocessor issue
Closed this issue · 9 comments
Comparing wcc and gcc output, they are almost identical, but it seems that wcc doesn't (sometimes?) hande redefines correctly.
TIMER_CLOSE is clearly (re-)defined as 1, however it's 39 in wcc output, from modoc.h. Maybe some flag is missing? I'm using wine ~/bin/wcc386.exe "$f" -p -fo="$f.tmp" -w4
A minor issue, but it should be noted.
I will be switching build to gcc anyway, since otherwise it works fine and certainly is faster.
scripts_src$ for f in $(find . -name "*.tmp"); do diff -uw $f ${f}2; done
--- ./modoc/mimirdor.ssl.tmp 2019-10-03 23:05:50.175759904 +0700
+++ ./modoc/mimirdor.ssl.tmp2 2019-10-03 23:05:50.227758792 +0700
@@ -115,10 +115,10 @@
obj_close(self_obj);
debug_msg("mimirdor" + ": " + "door is closed" + "\n");
end else begin
- add_timer_event(self_obj, 10, (39));
+ add_timer_event(self_obj, 10, (1));
end
end else begin
- add_timer_event(self_obj, 10, (39));
+ add_timer_event(self_obj, 10, (1));
end
end
end
@@ -172,7 +172,7 @@
end else begin
last_source_obj := 0;
end
- add_timer_event(self_obj, 10, (39));
+ add_timer_event(self_obj, 10, (1));
end
if ((((tile_num(self_obj)) == (15127)) and (cur_map_index == (19)))) then begin
if ((((global_var((297)) bwand (16)) != 0)) == false) then begin
--- ./modoc/midavdor.ssl.tmp 2019-10-03 23:05:45.887852056 +0700
+++ ./modoc/midavdor.ssl.tmp2 2019-10-03 23:05:45.935851020 +0700
@@ -115,10 +115,10 @@
obj_close(self_obj);
debug_msg("midavdor" + ": " + "door is closed" + "\n");
end else begin
- add_timer_event(self_obj, 10, (39));
+ add_timer_event(self_obj, 10, (1));
end
end else begin
- add_timer_event(self_obj, 10, (39));
+ add_timer_event(self_obj, 10, (1));
end
end
end
@@ -172,7 +172,7 @@
end else begin
last_source_obj := 0;
end
- add_timer_event(self_obj, 10, (39));
+ add_timer_event(self_obj, 10, (1));
end
if ((((tile_num(self_obj)) == (15127)) and (cur_map_index == (19)))) then begin
if ((((global_var((297)) bwand (16)) != 0)) == false) then begin
--- ./modoc/midoor.ssl.tmp 2019-10-03 23:05:46.651835585 +0700
+++ ./modoc/midoor.ssl.tmp2 2019-10-03 23:05:46.699834550 +0700
@@ -130,10 +130,10 @@
obj_close(self_obj);
debug_msg("midoor" + ": " + "door is closed" + "\n");
end else begin
- add_timer_event(self_obj, 10, (39));
+ add_timer_event(self_obj, 10, (1));
end
end else begin
- add_timer_event(self_obj, 10, (39));
+ add_timer_event(self_obj, 10, (1));
end
end
end
@@ -187,7 +187,7 @@
end else begin
last_source_obj := 0;
end
- add_timer_event(self_obj, 10, (39));
+ add_timer_event(self_obj, 10, (1));
end
if ((((tile_num(self_obj)) == (15127)) and (cur_map_index == (19)))) then begin
if ((((global_var((297)) bwand (16)) != 0)) == false) then begin
Interesting. Watcom seems ignoring the redefined macro completely (not even a warning message).
Tested with a minimal setup like this:
// mydefine.h
#define TIMERX (99)
// myscript.ssl
#include "mydefine.h"
#define TIMERX (1)
procedure start begin
variable var1 := TIMERX;
display_msg("Var1: " + var1);
end
Open Watcom produces: variable var1 := (99);
mcpp/GCC produce: variable var1 := (1);
Watcom produces var1 := 1 only if #define TIMERX (1) line is above #include "mydefine.h", so it's a "who first wins" case?
But in vanilla miDoor.int TIMER_CLOSE is redefined as 1, maybe the devs were actually using VC6 for preprocessing instead of Watcom as stated in the original sslc readme.
Too bad mcpp can't handle certain scripts (I think it's due to its 65535 chars per line limit), or we wouldn't need any standalone preprocessor for building scripts.
Probably trivial/useless info but because I don't use GCC (MinGW). I tested some more C/C++ preprocessors, surprisingly the nearly 20-year old Borland C++ compiler 5.5 (or newer rebranded Embarcadero C++) works pretty well in this case, as it can print warnings about macro redefinition and handle DCATKSLV.ssl properly, plus only requires a cpp32.exe. The only downside is it doesn't keep the indentation in preprocessed scripts.
While Orange C can redefine the macro in my example, it prints no warnings and fails to preprocess DCATKSLV.ssl properly (similar to mcpp). Also the issue about Watcom C compiler has been existed since at least Watcom 10.0 (found a copy on Internet Archive), guess for now using C++ compiler (wpp386) to preprocess scripts might be a better choice, at least it can redefine the macro.
For future reference, the bug is fixed in openwatcom v2, and anyone wanting to use it should be safe.
A new issue due to recent OpenWatcom updates: now it checks octal constants in the code more aggressively.
That means IQ values in ###Option(msg num, node num, IQ) macros in scripts are viewed as octal due to their leading zeros, and scripts with dialog options that require IN 8/9 will have "invalid octal constant" error during preprocessing by OpenWatcom.
I suppose other compilers/preprocessors just ignore octal literals or something. Not sure if it should be treated as a bug in newer OW, or it's better to simply remove all leading zeros from all IQ values in Option macros.
Well, current build uses gcc, and I don't know if anyone uses OW, so I don't really care.
0-prefixing does seem strange and I guess could be misleading to untrained eyes, so if anything were to be done, I think stripping 0's is a good option.
I use OW from time to time. The issue was noticed by someone else when batch-compiling UP scripts with sslc+OW. I opened an issue on OW repo to see if this octal checking behavior intended or maybe some bug in the code.
ok, let's see what they say
OK, it was a bug in the preprocessor (it's not supposed to check octal literals and likes). Now it's fixed so no need to batch edit the scripts.
cool