Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

problem with fix_str() in parser.lua #4

Closed
bbblitz opened this issue Aug 20, 2016 · 6 comments
Closed

problem with fix_str() in parser.lua #4

bbblitz opened this issue Aug 20, 2016 · 6 comments
Labels

Comments

@bbblitz
Copy link

bbblitz commented Aug 20, 2016

When given the string
"\\a"
The fix_str() function will make this into
"\\\a"
Instead of the correct
"\a"

This is the same for all escaped characters. (\b,\n,\r ect.)

@andremm
Copy link
Owner

andremm commented Sep 5, 2016

Can you please check whether this issue persists after latest changes?

@andremm
Copy link
Owner

andremm commented Sep 12, 2016

After latest changes, this bug still persists.
In fact, now even the following correct program does not parse:

x = "\\"

Parsing this program throws the following error message:

bug.lua:1:7: syntax error, unclosed string

@undecidabot, do you have any thoughts on this?

@andremm andremm added the bug label Sep 12, 2016
@lezgomatt
Copy link
Contributor

lezgomatt commented Sep 13, 2016

@andremm Hm, I can't seem to reproduce this bug (on latest commit of master). I'm pretty sure this case is already handled by https://github.com/andremm/lua-parser/blob/master/lua-parser/parser.lua#L415.

I could reproduce the exact error message if there's only one backslash as in

x = "\"

but that wouldn't be a bug then. Are any of the other escape characters also having this issue?

@andremm
Copy link
Owner

andremm commented Sep 13, 2016

Are any of the other escape characters also having this issue?

@undecidabot, this bug is a bit tricky. :)
And yes, I noticed it with other escape characters (I'm using Lua 5.3.3).

For instance, using the following test file (which I will call bug1.lua):

local parser = require "lua-parser.parser"
local pp = require "lua-parser.pp"

if #arg ~= 1 then
    print("Usage: parse.lua <string>")
    os.exit(1)
end

local ast, error_msg = parser.parse(arg[1], "example.lua")
if not ast then
    print(error_msg)
    os.exit(1)
end

pp.print(ast)
os.exit(0)

Running $ lua bug1.lua 'x = "\\"' works, but running $ lua t.lua "x = '\\'" does not work.

As another example, using the following test file (which I will call bug2.lua):

local parser = require "lua-parser.parser"
local pp = require "lua-parser.pp"

local ast, error_msg = parser.parse('x = "\\"', "example.lua")
if not ast then
    print(error_msg)
else
    pp.print(ast)
end

local ast, error_msg = parser.parse("x = '\\'", "example.lua")
if not ast then
    print(error_msg)
else
    pp.print(ast)
end

os.exit(0)

Both examples don't work when running $ lua bug2.lua.

However, both examples should work, as we can see in the following Lua test:

Lua 5.3.3  Copyright (C) 1994-2016 Lua.org, PUC-Rio
> x = '\\'
> print(x)
\
> x = "\\"
> print(x)
\
>

@lezgomatt
Copy link
Contributor

@andremm It took a while, but I've figured it out. There is no bug 😄

For bug1.lua, $ lua t.lua "x = '\\'" fails because the shell escapes characters on double quoted strings, turning the two backslashes into just a single backslash when passed to Lua.

$ echo '\\'
> \\
$ echo "\\"
> \

Similarly, for bug2.lua, the characters are being escaped, but this time by Lua. So again, there is only one backslash which is followed by the quote, making the string unclosed just as the error reports. If we change the \\ into \\\\, or use long strings instead, no error will be reported.

This bug was definitely confusing, but I think we can mark it as resolved now 😄

@bbblitz bbblitz closed this as completed Nov 18, 2016
@andremm
Copy link
Owner

andremm commented Dec 9, 2016

This bug was definitely confusing, but I think we can mark it as resolved now 😄

You're right @undecidabot. I'm sorry I took too long to reply, but that's great that @bbblitz already closed the issue. Thanks for your feedback!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

3 participants