News for hackers. Stuff that matters.
Re:Rust 2024 the Year of Everywhere? by Gibbon1 on Friday September 23, 2022 @02:38AM (#32948762)
> or return a pointer to a local variable that's about to go out of scope

I thought of that recently. I wonder about using escape analysis to detect that and simply don't release the stack frame until the reference goes out of scope.

Re:Rust 2024 the Year of Everywhere? by mikepurvis on Friday September 23, 2022 @10:27AM (#32952394)
Static analysis/tracing absolutely can do a bunch of that kind of thing, particularly catching trivial cases.

But I think it's still a pretty important upgrade when those things are being checked by the compiler, for free, with guarantees, as part of every build, rather than using some side-tool that may be proprietary, deliver oodles of false positives, and so on.

Re:Rust 2024 the Year of Everywhere? by Gibbon1 on Friday September 23, 2022 @03:30PM (#32956086)
What I mean is just fix that so it works. If you have split stacks the one for data doesn't have to track function call chains.

The advantage of using analysis tools is you only pay for that once. Not with every compile. And the tools are smarter than Rust. You also don't have safe vs unsafe code like you do with Rust.

Re:Rust 2024 the Year of Everywhere? by int_19h on Saturday September 24, 2022 @01:36AM (#32959970)
You wouldn't just need split stacks for this, you'd need a spaghetti stack with some kind of heap allocation for frames. At which point perf goes out of the window already.
Re:Rust 2024 the Year of Everywhere? by pjmlp on Saturday September 24, 2022 @08:59AM (#32962163)
If you are using gcc, clang or vc++, to certain extent that is part of the compiler.

Just like C, following the UNIX principle, had compiler, assembler, linker, makefile, and linter since 1979. But people kept forgetting about the last piece of the puzzle and now it is a pain to bolt into existing code.