Parsing bug in blitzmx compiler
Archives Forums/BlitzMax Bug Reports/Parsing bug in blitzmx compiler
| ||
| Hey ppl. I found a small bug in the code parser of the blitzmax compiler. It concerns arrays. This occurs in blitzmax 1.30 (svn threading build) SuperStrict Framework brl.basic Local arr:String[] = ["abc" . "def"]; '// notice the dot here ^ should be a comma. Print(arr[0]); '// prints 'def' instead of 'abc'. Print(arr[1]); '// should be 'def', but throws 'out of bounds' error First off, this compiles without an error, eventhough the dot is there instead of a comma. Secondly, it causes the parser to completely ignore the first array entry. |
| ||
| Maybe the parser reads the '.' like '0.5' (you can write .5) and it considers the first parameter as 0 (or void for string)? Confirm the error in Bmax 130 SVN 171 |
| ||
This must happen because strings are objects. I think it is more of an unintended side effect than a bug.Framework brl.basic Print Print "abc".length Print "abc"."def" |
| ||
| I think it is more of an unintended side effect than a bug. No, it is definitely a bug. This throws a compile error: Print ("Hello")."World"Whereas this compiles: Local i:Int Print i."Hello World!" A parser error, like Jim T wrote above. |
| ||
| I would say it is definitely a bug, maybe. The docs give the syntax for Print as Function Print( str$="" ) In your second example a string has been built from integer i. This object has a "Hello World!" field, whatever that means. The first example won't compile, but Print ( ("Hello")."goodbye" ) is okay. I guess this says something about the precedence of the dot operator.Bug or not it is certainly peculiar. |
| ||
| Hi, Well, it's kind of a 'feature'... The way Max works, consts exist in all scopes - ie: you can use them anywhere. So stuff like obj."string" means the const "string" was found in obj's scope! This is 'right', but obviously a little icky. Will have a look into this soonish. |
   |