Hacker News new | ask | show | jobs
by bb88 16 days ago
How does it deal with pointers if everything is stack based? You can't really return a pointer to something on the stack because it could get overwritten between when you return it and when you access it.
2 comments

Exactly as well as C does, it seems.

    func newPerson() *Person {
        p := Person{Name: "Alice", Age: 30}
        return &p
    }
becomes

    static main_Person* newPerson(void) {
        main_Person p = (main_Person){.Name = so_str("Alice"), .Age = 30};
        return &p;
    }
Quoting the FAQ: "So itself has few safeguards other than the default Go type checking. It will panic on out-of-bounds array access, but it won't stop you from returning a dangling pointer or forgetting to free allocated memory. Most memory-related problems can be caught with AddressSanitizer in modern compilers, so I recommend enabling it during development by adding -fsanitize=address to your CFLAGS."

So saying you get the "safety of Go" is a bit of a stretch.

Yeah that's not great. It's easy to be faster than go if you haven't thought about memory management yet. I bet go with GOGC=off is faster than plain go too.
This is impossible. General words like "faster" are subjective, and useless in a technical context unless you ground the discussion by giving them specific definitions. Otherwise everyone ends up talking past each other.
Whoa, I have my very first crazy internet stalker. What fun!

Do an internet search for "go garbage collector benchmark" if you're curious what the grownups are talking about.

That's undefined behavior in C I thought? You're addressing the memory of a stack frame that already collapsed when it returned. I think it's ok for compilers to either segfault or work like you'd think they would for that example in C.

You can pass pointers to earlier frames in the stack, they're still active, but you can't return a pointer to an expired stack frame.

I think you're basically agreeing with the person you're replying to; they're pointing out that Solod doesn't really provide the "safety of Go" since the translation trivially exposes the user to UB that would not be present in Go.
You're right, I misread their point, sorry for the pedantry OP.
Well, it does say:

"Everything is stack-allocated by default; heap is opt-in through the standard library."

So it supports both stack and heap, and I guess static allocation too.