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

Duplicated variable declaration BUG #461

Closed
mingodad opened this issue Dec 27, 2018 · 1 comment
Closed

Duplicated variable declaration BUG #461

mingodad opened this issue Dec 27, 2018 · 1 comment

Comments

@mingodad
Copy link

Hello !

I did posted before https://www.freelists.org/post/luajit/Probably-a-bug-of-duplicated-variable-declaration but it seems that it doesn't got the attention it deserves, probably my fault in not give a good explanation.

The problem was discovered while translating luajit to https://github.com/mingodad/ljsjit .

In ljs I decided to have the compiler to flag error/warning when a variable is redeclared and in doing so it flagged the code mentioned on the previous post (see link above).

In dynasm/dasm_mips.lua and dynasm/dasm_ppc.lua in function "op_template" there is some local declarations that are used inside a big loop, one of these variables "n" is incremented on each iteration of the loop and reused again, but in one of the many if/elseif blocks it's redeclared and shadow the previous declared one used incrementally in the loop, and inside the same block use it with the intention of change the first declaration to be reused in the loop BUT BECAUSE IT WAS SHADOWED BY A BLOCK REDECLARATION IT'LL NOT.

====luajit 2.1:dynasm/dasm_mips.lua:811

elseif p == "B" or p == "J" then
  local mode, n, s = parse_label(params[n], false)  --??? here we have the variable n shadowed 
  if p == "B" then n = n + 2048 end
  waction("REL_"..mode, n, s, 1)
  n = n + 1   --??? here it seems that you do not want a local shadowed variable 
elseif p == "A" then

====

This seem to be a common mistake in lua that could be prevented by the compiler like ljs does.

Since that post I could see that Mike Paul the author of the code have replied to other message but seems to not taking in account it, again probably by my very short explanation on that post.

So I expect that with this new post the problem can be reviewed and fixed.

Thanks for your great work and dedication !

Cheers !

@MikePall
Copy link
Member

Fixed. This couldn't trigger a bug, since labels are always the last parameter.

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

No branches or pull requests

2 participants