Empty string processed by empty receiver

[jeshecdom]

In this contract:

contract Test {

    receiver: String = "unknown";
    
    receive() {
       self.receiver = "empty";    
    }

    receive(msg: String) {
       self.receiver = "string";
    }
}

If we send a message with an empty string (done in a spec.ts file):

await contract.send(
      treasure.getSender(),
      { value: toNano("10") },
      "",
);

the message will get processed by the empty receiver, when it should be processed by the String receiver, because the body has an opcode of 0 with an empty string.

As a comparison, the following contract correctly catches the above message in the string receiver:

contract Test {

    receiver: String = "unknown";
    
    receive(msg: String) {
       self.receiver = "string";
    }
}

I tried sending a message to the contract inside Tact:

send(SendParameters{to: contractAddr, value: ton("1"), body: "".asComment()})

And again, the empty receiver processes the message.

The problem is that in the generated FunC code, the handler for the empty receiver has a <= 32 comparison:

    ;; Receive empty message
    if ((op == 0) & (slice_bits(in_msg) <= 32)) {
        self~%$Test$_internal_empty();
        return (self, true);
    }

and I think it should be strict inequality < 32.

Additionally, the case for empty string should be added to the tests in src/test/e2e-emulated/receiver-precedence.spec.ts.

[anton-trunov]

Try typechecking

contract Test {
    
    receive("") {
       self.receiver = "empty";    
    }
}

[jeshecdom]

Try typechecking

contract Test {

receive("") {
   self.receiver = "empty";    
}

}

Interesting. The compiler gives the error: "To use empty comment receiver, just remove parameter instead of passing empty string".
So, the actual semantics is that the empty string is a en empty body. In fact, any message that contains less than or equal to 32 bits in its body, with opcode 0, is considered to be an empty message. Then, it is not a bug. =D

[jeshecdom]

Then, it should be stated somewhere in the docs.

[anton-trunov]

Then, it should be stated somewhere in the docs.

Absolutely!