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

Working with Lua 5.2 #1

Open
winstonwolfe06 opened this issue Jul 9, 2018 · 12 comments
Open

Working with Lua 5.2 #1

winstonwolfe06 opened this issue Jul 9, 2018 · 12 comments

Comments

@winstonwolfe06
Copy link

Just wanted to note some challenges that I had while working with the runtime dependencies working with Lua 5.2 (which is what Wireshark comes with) vs Lua 5.3:

Bitwise operations needed to be modified to not use the standard symbols but instead utilize the bit32 supported ones:
https://www.lua.org/manual/5.2/manual.html#6.7

Also string.unpack is not supported whereas Struct.unpack is and provides the same behavior.

All of these changes were made in the kaitaistruct.lua file.

@GreyCat
Copy link
Member

GreyCat commented Jul 9, 2018

Thanks! Do I get it correctly that it's possible to create a runtime which would work with both 5.2 and 5.3? If yes, could you prepare a pull request for these changes?

Bitwise operations needed to be modified to not use the standard symbols

I believe that it would be not affect the runtime, but also would require some changes in code generation as well?

Cc @adrianherrera

@adrianherrera
Copy link
Member

Yeah, I think this will require changes to the translator as well (e.g. for bitwise operations).

@cherue
Copy link
Contributor

cherue commented Mar 12, 2020

Note that the struct.unpack mentioned refers to http://www.inf.puc-rio.br/~roberto/struct/#unpack which was incorporated into Lua 5.3 as string.unpack.

Also the Lua 5.3 Reference Manual states:

Keep in mind that bit32 operates on 32-bit integers, while the bitwise operators in Lua 5.3 operate on Lua integers, which by default have 64 bits.

Lua 5.3 includes bit32 by default for compatibility but it will be removed completely in Lua 5.4.

@smarek
Copy link

smarek commented Jul 30, 2020

There are multiple syntax and module issues, Translator needs to be updated, but i want to ask, before I'll commit myself to the cause. I'm currently motivated, because of Wireshark integration I'd want to pursue, see OK-DMR/Hytera_Homebrew_Bridge#1
that
@GreyCat @generalmimon there are two way, in my opinion, how to achieve Lua 5.2 support

  1. Update the translator and runtime to use iryont/lua-struct and BitOp, similar to what kaitai_struct_luajit_runtime already did
  2. Create Lua52Translator and kaitai_struct_lua52_runtime, that would do the same but separately, instead of forcing 5.3 users to use non-native bitop/struct (or maybe the lua version support level, could be just configuration option to kaitai-struct-compiler and only 5.2 runtime would be published separately?)

Could you please comment on, which of those ways you are more comfortable with?

@Qix-
Copy link

Qix- commented Aug 7, 2020

Why not make it 5.1 compatible, too? That would enable LuaJIT users, too.

@KOLANICH
Copy link

KOLANICH commented Aug 7, 2020

Shouldn't wireshark just upgrade the lua version?

@Qix-
Copy link

Qix- commented Aug 7, 2020

@KOLANICH Not as easy as it sounds. There are breaking API changes.

@smarek
Copy link

smarek commented Aug 7, 2020

@KOLANICH it might happen in Wireshark release 3, however when that will happen is unknown, and I'm not sure Wireshark devs have the motivation to do so. And as @Qix- said, could be 5.1 compatible even, however since Lua is not my standard knowledge, i'm not sure if 5.1 code is straight 5.2 compatible

@Qix-
Copy link

Qix- commented Aug 9, 2020

By the way, to be clear, yes you can write portable Lua. Just requires ponyfilling a few libs (e.g. bit vs bit32, table.unpack vs unpack, etc.)

@smarek
Copy link

smarek commented Aug 9, 2020

Great, so now the only thing remaining is the decision, do we want a separate translator for Lua and separate Lua 5.1+ compatible runtime, or do we want to update the current translator to directly produce Lua 5.1+ compatible code instead?

@GreyCat
Copy link
Member

GreyCat commented Aug 9, 2020

Judging by previous experience, if we can afford doing cross-platform, and it's not terribly bad in terms of performance or having tons of ifs, it's much better user experience and simpler testing if we do cross-platform.

@smarek
Copy link

smarek commented Aug 10, 2020

So I think I've done it all, and this ticket can be closed in favor of #5

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

No branches or pull requests

7 participants