5 ms·

The language was trivial to break in a few minutes. (And it likely can't do anything about it [edit to make this clear: This is not an implementation bug. Witho

The language was trivial to break in a few minutes. (And it likely can't do anything about it [edit to make this clear: This is not an implementation bug. Without depended types or abstract interpretation this is unfixable¹, as I see it]). module body Test is function recur(n: Nat64): Nat64 is if n < 2 then return n; else return recur(n - 1); end if; end; function main(): ExitCode is print("recur(50000000) = "); printLn(recur(50000000)); return ExitSuccess(); end; end module body. This code generates almost 3.5 kLOC of C which results in a segmentation fault when compiled and run on my machine. I'm not impressed to be honest. I would be less harsh if this wouldn't be advertised as sane and safe language. But it is. --- ¹ Of course you could fix this with for example trampolining. But than the promise of "no hidden control flow or functions calls or allocations" would be broken instantly.

docandrew 4y ago
This is a bit harsh. It’s still early in the language’s development, and the quality of the compiler/generated code shouldn’t be conflated with the principles of the language itself.
- still_grokking 4y ago
  It does crash "on principle" though. That's not an implementation bug! If you `recur` less often it works just fine. Like I said, the language as such can't catch such bugs, as I see it.
  - docandrew 4y ago
    That’s not a bug, it’s a limitation of your operating environment. Increase the stack size and it would work. What else would you expect to happen?
    - still_grokking 4y ago
      > That’s not a bug, […] Yes, I've mentioned this. > […] it’s a limitation of your operating environment. No, it isn't. Memory is finite. If your language doesn't handle this fact it's inherently unsafe, and a ticking time bomb. > What else would you expect to happen? Simply: No random crashes. Especially as such a crash relies on the environment where the code is run. So it may work just fine "on your machine" but than crash in production… That's imho a big no-no for anything that wants to be a "safe systems language" (especially as the post is mentioning things like nuclear power plants as target audience).
  - JonChesterfield 4y ago
    Uh, that one is an implementation bug. It's presumably compiling the call to recur as a normal C call. It should either be a goto (or loop, w/e) or use the musttail compiler extension.
zetalyrae 4y ago
Yes, it's a stack overflow. It's fixed by adding the appropriate flags to the underlying compiler.
- still_grokking 4y ago
  I've used the flags given in the readme on GitHub. gcc -fwrapv generated.c -lm But anyway (besides that this is a lazy answer as it sounds like "not my problem"), how could a C compiler prevent this in the general case? To play devil's advocate: Why not stick with C as it seems to be the more "secure" language in this case? (Even we all know that C is inherently insecure, which is the reason for alternative system languages in the first place).
  - zetalyrae 4y ago
    It's not a problem of the language's semantics, which state that stack overflow should trap: https://austral-lang.org/spec/spec.html#rationale-errors https://austral-lang.org/spec/spec.html#rationale-errors Trapping on overflow requires passing a flag to GCC. I didn't list that in the readme because there's like fifty other hardening flags like that and it would overcomplicate the presentation. I'll certainly add it to the build system, when it exists.

docandrew 4y ago

This is a bit harsh. It’s still early in the language’s development, and the quality of the compiler/generated code shouldn’t be conflated with the principles of the language itself.

still_grokking 4y ago
It does crash "on principle" though. That's not an implementation bug! If you `recur` less often it works just fine. Like I said, the language as such can't catch such bugs, as I see it.
- docandrew 4y ago
  That’s not a bug, it’s a limitation of your operating environment. Increase the stack size and it would work. What else would you expect to happen?
  - still_grokking 4y ago
    > That’s not a bug, […] Yes, I've mentioned this. > […] it’s a limitation of your operating environment. No, it isn't. Memory is finite. If your language doesn't handle this fact it's inherently unsafe, and a ticking time bomb. > What else would you expect to happen? Simply: No random crashes. Especially as such a crash relies on the environment where the code is run. So it may work just fine "on your machine" but than crash in production… That's imho a big no-no for anything that wants to be a "safe systems language" (especially as the post is mentioning things like nuclear power plants as target audience).
- JonChesterfield 4y ago
  Uh, that one is an implementation bug. It's presumably compiling the call to recur as a normal C call. It should either be a goto (or loop, w/e) or use the musttail compiler extension.

zetalyrae 4y ago

Yes, it's a stack overflow. It's fixed by adding the appropriate flags to the underlying compiler.

still_grokking 4y ago
I've used the flags given in the readme on GitHub. gcc -fwrapv generated.c -lm But anyway (besides that this is a lazy answer as it sounds like "not my problem"), how could a C compiler prevent this in the general case? To play devil's advocate: Why not stick with C as it seems to be the more "secure" language in this case? (Even we all know that C is inherently insecure, which is the reason for alternative system languages in the first place).
- zetalyrae 4y ago
  It's not a problem of the language's semantics, which state that stack overflow should trap: https://austral-lang.org/spec/spec.html#rationale-errors https://austral-lang.org/spec/spec.html#rationale-errors Trapping on overflow requires passing a flag to GCC. I didn't list that in the readme because there's like fifty other hardening flags like that and it would overcomplicate the presentation. I'll certainly add it to the build system, when it exists.