Issue #13 fix display long int, sprintf, uninitialized variables

bertysentry commented 6 years ago

issue #13

Fixed the handling of large integers
Fixed the handling of uninitialized variables
Fixed the sprintf() function (and related) to behave like GNU AWK (gawk)

bertysentry commented 6 years ago

I just rebased my changes onto the latest master. Will reopen.

eyalroth commented 6 years ago

What issue is this PR for? (I can't find issue 12).

bertysentry commented 6 years ago

ugh... I can't get issue numbers right. Sorry about that. This is issue #13 , and related bugs (variable types and displaying these)

bertysentry commented 6 years ago

Hi @eyalroth ! Quick comment: I imported my Jawk repo (fork of this one) into BitBucket, and BitBucket does show the modifications of AwkCompilerImpl.java. I'm not sure of what is going on with GitHub here... :-/

bertysentry commented 6 years ago

Hi @eyalroth Regarding Long vs Integer, try this with GAWK:

$ echo | gawk 'END { a = 123456789001 ; print a }'
123456789001
$

If you try the same with Jawk, you will get:

$ echo | java -jar target\jawk-1.03-SNAPSHOT-stand-alone.jar "END { a = 123456789001 ; print a }"
ERROR - Unexpected state
java.lang.NumberFormatException: For input string: "123456789001"
        at java.base/java.lang.NumberFormatException.forInputString(Unknown Source)
        at java.base/java.lang.Integer.parseInt(Unknown Source)
        at java.base/java.lang.Integer.parseInt(Unknown Source)
        at org.jawk.frontend.AwkParser$AwkSymbolTableImpl.addINTEGER(AwkParser.java:5093)
        at org.jawk.frontend.AwkParser.FACTOR(AwkParser.java:1287)
        at org.jawk.frontend.AwkParser.FACTOR_FOR_INCDEC(AwkParser.java:1229)
        at org.jawk.frontend.AwkParser.FACTOR_FOR_IN(AwkParser.java:1197)
        at org.jawk.frontend.AwkParser.FACTOR_FOR_GETLINE(AwkParser.java:1180)
        at org.jawk.frontend.AwkParser.TERM(AwkParser.java:1151)
        at org.jawk.frontend.AwkParser.EXPRESSION(AwkParser.java:1083)
        at org.jawk.frontend.AwkParser.COMPARISON_EXPRESSION(AwkParser.java:1063)
        at org.jawk.frontend.AwkParser.LE2_EXPRESSION(AwkParser.java:1043)
        at org.jawk.frontend.AwkParser.LE1_EXPRESSION(AwkParser.java:1025)
        at org.jawk.frontend.AwkParser.TERTIARY_EXPRESSION(AwkParser.java:1009)
        at org.jawk.frontend.AwkParser.CONCAT_EXPRESSION(AwkParser.java:990)
        at org.jawk.frontend.AwkParser.COMMA_EXPRESSION(AwkParser.java:970)
        at org.jawk.frontend.AwkParser.ASSIGNMENT_EXPRESSION(AwkParser.java:950)
        at org.jawk.frontend.AwkParser.ASSIGNMENT_EXPRESSION(AwkParser.java:958)
        at org.jawk.frontend.AwkParser.EXPRESSION_STATEMENT(AwkParser.java:1572)
        at org.jawk.frontend.AwkParser.STATEMENT(AwkParser.java:1555)
        at org.jawk.frontend.AwkParser.STATEMENT_LIST(AwkParser.java:918)
        at org.jawk.frontend.AwkParser.RULE(AwkParser.java:888)
        at org.jawk.frontend.AwkParser.RULE_LIST(AwkParser.java:796)
        at org.jawk.frontend.AwkParser.SCRIPT(AwkParser.java:779)
        at org.jawk.frontend.AwkParser.parse(AwkParser.java:337)
        at org.jawk.Awk.invoke(Awk.java:149)
        at org.jawk.Main.invoke(Main.java:113)
        at org.jawk.Main.main(Main.java:71)

So, Jawk is definitely not behaving like GAWK, and dealing with number greater than 2^32 is pretty common nowadays. This absolutely needs to be fixed. Performance impact is actually minimal (compared to what is done in the rest of the code, I mean ;-) )

bertysentry commented 6 years ago

I agree with your comment on having separate PRs. The problem is that I first believed the project was no longer actively maintained. So I went and I went further with modifications that, at first, seemed simple, but that have much more ramifications than anticipated.

All in all, these modifications are about:

handling long numbers (like GAWK)
displaying numbers (like GAWK)
handling Uninitialized variables properly (that could be in a separate PR, but it has also many ramifications, so it's very difficult to sort it out afterward :-/ )
one small fix on (0 == "") evaluation

I'll see what I can do to split the PRs, but I can't promise anything here...

Also, this PR is for a branch, that is based on the previous branch I submitted a PR for. So, once the previous PR is merged, this PR will be updated automatically to show only the remaining commits.

This should have been done differently, I agree (working alone is not the same thing as working in a team, my apologies!)

eyalroth commented 6 years ago

Hmm I see, I thought gawk was limited to 32bit integers but I was wrong. This feature is indeed fundamental. Well, there's more work to be done for this to be complete :) take a look at my notes.

hoijui / Jawk

Issue #13 fix display long int, sprintf, uninitialized variables #14