FunC quirks

I was criticized for criticizing FunC stability, i even got two "security audits". I must admit, i haven't read them. But i know their results from friend from Ton Foundation. It sound something like "it crashes sometimes, but never emit incorrect code". It didn't occurred to me that this certification couldn't be trusted then. Just recently there were fixes in FunC and i will show you what was fixed and how this could be marked as "never emit incorrect code" is beyond my understanding. Yes, Durov probably built it this way, but no developer would expect the code to behave like this. I will iterate over the major issues that i hit during over a year of building smart contract on FunC.

All this issues are resolved, but this always was a dangerous game when playing with FunC and it is not clear what still broken.

Bug in stdlib

One of the most bizzare issues was in stdlib itself. It turns out that command allows you to read a Cell reference from a dictionary simply breaks call stack that could lead to a total catastrophe. Moreover this issue was well-known, but no one fixed it in repository (???). Eventually it was ironed out, but it took several months to fix this. I just wonder how many people hit this issue? This is an old bug, but FunC was still "production ready" and everywhere it was marked as a go-to language for TON. This bug was before audit.

Broken Branches

This is another critical issue in FunC, it also breaks your call stack, but this time this was very hard to reason about. Basically if you have two branches of code that has different stack size, it would break in some cases. This bug was very nasty, basically no contract could work without some extra careful testing. There are also were no code coverage so it was really challenging to check if we hit all the branches and haven't hit the bug. This bug was before audit. But language was promoted everywhere as the thing that developers must use.

Execution of expressions with multiple operations

This bug was fixed just recently. First it was fixed by throwing an exception (compile-time) when conditions are met and expression couldn't be calculated. This was a huge issue for Tact since it is not clear how to perform such checks on Tact level and the only fallback was just crashing in FunC. Then it was fixed in an appropriate way, but you have to EXPLICITLY enable this fix. Thankfully it would still crash and won't compiler instead of literally emitting broken code.

This code would make variable b equal to variable sc. Basically if it sees an expression it would evaluate it after processing all simple variables. This is wildly incorrect for any developer.

The second issue is calling stdlib functions that has argument reordering. It was fixed in latest version, but you still have to manually enable this fix. This issue is about the same as the one above, but it is MUCH worse since it is not obvious at all and there are no compiler crash right now. This bug exists for most of stdlib methods that work with dictionaries. In next example the actual arguments would be (v, 2, 1):

This bug is popular in stack-based languages. One of such bugs currently exists in Tact too, but going to be fixed before first production release.

This is clearly a very nasty bug that could lead for something very unexpected and i don't know who managed to mark this such compiler as the one that doesn't emit broken code.

Summary

FunC has it's problems. As i have seen on GitHub it didn't get enough love from Core Developers, barely any contributions from outside. It still has bugs and sometimes produces incorrect code. You have to always test all your contracts using foreign language (such as typescript) and be sure that everything would work anyway.