Space(s) are eaten in front of hex numbers
ayourtch opened this issue · comments
processing this input:
return 0xff;
results in the following output:
return255;
Conversion to decimal is probably OK (though nominally preprocessor should not do it), but eating up the space before is a problem.
The following diff takes care of it:
diff --git a/lcpp.lua b/lcpp.lua
index e60f225..be6c34b 100755
--- a/lcpp.lua
+++ b/lcpp.lua
@@ -462,7 +462,7 @@ local function parseCInteger(input)
elseif k == "HEX_LITERAL" then
unary, v = v:match('([%+%-]?)0x([a-fA-F%d]+)[UL]*')
local n = tonumber(v, 16)
- table.insert(out, unary..tostring(n))
+ table.insert(out, " "..unary..tostring(n))^M
elseif k == "NUMBER_LITERAL" then
v = v:match('([^UL]+)[UL]+')
table.insert(out, v)
Hey,
Lets always construct testcases for changes including the issue number like this
msg = "#issue25 test - HEXVALUE stripped spaces"
define ISSUE_25 { return 0xFF; }
assert(...)
...
I was not sure how to properly make a testcase, still wrapping my head around the mix of lua and cpp in that part of the code :) I'll do a second pass once I get it working in its entirety. (I will probably have to reset/redo the commits anyway in my fork, since among the bugfixes there is also a small feature to implement the search path so one could do "#include <stdio.h>" and have it work. Sorry for creating so many issues, hopefully you do not mind! :)
Try to run make test
and see that there are strict testcases for any syntax and logic issues. If there is a bug, construct a valid testcase that we can talk about.
I toyed a bit more and see how they work now. I've dug a few more issues. So I will create a commit with the testcases for all, then create separate commit per issue with the fix, and then make a PR. Would that work ok ?
If its separated and includes testcases, yes absolutely.