Skip to content

Space(s) are eaten in front of hex numbers #25

Open

Description

@ayourtch

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.

Activity

  1. ayourtch commented on Aug 17, 2016

    @ayourtch
    Author

    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)
  2. m-schmoock commented on Aug 18, 2016

    @m-schmoock
    Owner

    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(...)
    ...
  3. ayourtch commented on Aug 18, 2016

    @ayourtch
    Author

    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! :)

  4. m-schmoock commented on Aug 18, 2016

    @m-schmoock
    Owner

    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.

  5. ayourtch commented on Aug 18, 2016

    @ayourtch
    Author

    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 ?

  6. m-schmoock commented on Aug 18, 2016

    @m-schmoock
    Owner

    If its separated and includes testcases, yes absolutely.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions