Strange execution with forward declared void

Any idea what is going on here...

With this code, I get the runtime error "unassigned variable (oBufer)" on line 7:

bool OverloadedFunction(void)

bool OverloadedFunction(Buffer oBufer) {
        print "bool OverloadedFunction(Buffer oBufer)\n"
        print "\tBuffer length: "
        print (length(oBufer)) "\n"
        bool b = OverloadedFunction()
        return b
}

bool OverloadedFunction() {
        print "bool OverloadedFunction()\n"
        return true
}

Buffer oBufer = create()
oBufer = "Text"
print "Buffer length: "
print (length(oBufer)) "\n"
bool b = OverloadedFunction(oBufer)
delete(oBufer)

If I change it slightly to remove the bool variable, it runs, but gives the wrong buffer length:

bool OverloadedFunction(void)

bool OverloadedFunction(Buffer oBufer) {
        print "bool OverloadedFunction(Buffer oBufer)\n"
        print "\tBuffer length: "
        print (length(oBufer)) "\n"
        return OverloadedFunction()
}

bool OverloadedFunction() {
        print "bool OverloadedFunction()\n"
        return true
}

Buffer oBufer = create()
oBufer = "Text"
print "Buffer length: "
print (length(oBufer)) "\n"
bool b = OverloadedFunction(oBufer)
delete(oBufer)

Removing the void from the forward declaration fixes it, as does removing the forward declare and swapping the order of the functions.

Just wondering what is getting passed as a Buffer in these two cases.

I'm guessing that a stack address is used and the bool alters the stack, but the error is before declaring the bool...

Re: Strange execution with forward declared void
Addam - Mon Nov 26 10:48:34 EST 2018

Error is on line 6, not 7.

I have tried to edit the post, but just get kicked to the "Spam" page every time I change that 1 character...

This forum is terrible

Re: Strange execution with forward declared void
davidcs - Tue Nov 27 08:01:39 EST 2018

bool OverloadedFunction()

bool OverloadedFunction(Buffer oBufer) {
        print "bool OverloadedFunction(Buffer oBufer)\n"
        print "\tBuffer length: "
        print (length(oBufer)) "\n"
        return OverloadedFunction()
}

bool OverloadedFunction() {
        print "bool OverloadedFunction()\n"
        return true
}

Buffer oBufer = create()
oBufer = "Text"
print "Buffer length: "
print (length(oBufer)) "\n"
bool b = OverloadedFunction(oBufer)
delete(oBufer)

I don't declare functions often,  but looking at some of my previous stuff when I do I never put the 'void' in the argument list. Maybe someone else can explain the 'why'.

Re: Strange execution with forward declared void
Mathias Mamsch - Tue Nov 27 11:25:25 EST 2018

bool OverloadedFunction()

bool OverloadedFunction(Buffer oBufer) {
        print "bool OverloadedFunction(Buffer oBufer)\n"
        print "\tBuffer length: "
        print (length(oBufer)) "\n"
        return OverloadedFunction()
}

bool OverloadedFunction() {
        print "bool OverloadedFunction()\n"
        return true
}

Buffer oBufer = create()
oBufer = "Text"
print "Buffer length: "
print (length(oBufer)) "\n"
bool b = OverloadedFunction(oBufer)
delete(oBufer)

The DXL syntax unfortunately is ambiguous and the parser is badly implemented. Stuff like this can confuse the parser:

string test(string s) {
    return "1" s;
}

string test () {
    return "2"; 
}

string s = test "3" test  
// ist this now   
// a) test("3" test())  --> 132 or 
// b) test() "3" test() --> 131 or 
// c) test("3") test() --> 131 ?

print s // 113 ????????

// Nothing of all ;-) Weird BUG!

Regarding the why has this been done - its probably a desire to be able to have the speaking syntax

string s =  richText attribute "..."

like which introduces  two factors that do constitute the ambiguity:

a) The possibility to make function calls without braces (for functions with 0 or 1 parameters)

b) The possibility to have functions with one parameter with the same name but different return types

c) The possibility to do string chaining the same way as function chaining

Taking into account that there is also a global DXL context where functions are loaded outside of your DXL and the forward declaration part makes the parser so hopelessly complicated that any hope of improvement is out of the window. So you have to live with it and make sure you don't do stuff like this.

Hope this helps, regards, Mathias

Re: Strange execution with forward declared void
Addam - Tue Nov 27 11:49:09 EST 2018

string test(string s) {
    return "1" s;
}

string test () {
    return "2"; 
}

string s = test "3" test  
// ist this now   
// a) test("3" test())  --> 132 or 
// b) test() "3" test() --> 131 or 
// c) test("3") test() --> 131 ?

print s // 113 ????????

// Nothing of all ;-) Weird BUG!

string s =  richText attribute "..."

I found this when running some 10+ year old code was acting as if a Buffer was null which it wasn't. Pretty sure it didn't do that before as I would have noticed when I wrote it.

So debugging to a smaller snippet that has the same-ish issue led me to this.

I don't see what part of the code is ambiguous, so I guess I just wondered if you had any insight on why the change to line 7 solves the crash, but gives the wrong answer.

Re: Strange execution with forward declared void
Mathias Mamsch - Wed Nov 28 09:34:01 EST 2018

Well the problem is the forward declaration of a function with a "void" parameter. In the parser there is some code, that checks how many parameters are supposed to be passed on the stack (via reference or not). As it seems to me this code mistakes the forward declaration

bool OverloadedFunction(void)

as a declaration for your bool OverloadedFunction(Buffer) therefore it will not pass the buffer to the function when you call it. Therefore you are missing one stack entry. When you introduce now a boolean variable inside the function the buffer will point to that (unassigned) boolean and you get an "Unassigned Variable" error, when trying to access buffer. If you remove the boolean, the buffer inside the function will simply point to the first item on the stack (that was left there by some other function call, probably the result of the previous string concatenation) so you might see a wrong length (probably the contents of the string interpreted as length).

When looking at the program with progPrint_ it seems it is taking the buffer from the stack. But in the end it does not matter. Just name functions differently when you have functions without or with one parameter. Chances are always that the DXL Parser will screw up on them and mistake one for another.

Regards, Mathias