undefined

points

by landr0id6 hours ago |

comments

by minraws4 hours ago|

[-]

I as someone with writing Zig a bunch, can safely say if it does it hasn't even worked for me.

I am talking from experience from a pre-ai human mitts writing code perspective maybe Zig + LLMs do some magic.

The more I read the article the more I feel like this is just bad not sure if I should be giving it as much latitude as I have been in my prior comments.

There are other claims as well that are weirdly phrased at least.

Reads like an article written to justify some arguments they had rather than a genuine take at this point.

But I will give the benefit of doubt I enjoy weird articles, languages and share a dislike for aggressive AI-ness of all things.

by veber-alex5 hours ago|

prev|

[-]

I believe you are correct.

I think ReleaseSafe just adds bound checking and panics on unreachable code.

I don't think Zig offers any temporal memory safety.

by Quot2 hours ago|

parent|

[-]

I don't know enough about Zig to explain it, but there is more to ReleaseSafe than checks and panics. ReleaseSafe also clears memory that no longer has an owner (I might be describing that wrong, that is just how I understand it). I found this out with a rendering issue recently.

The bug was around passing a slice to OpenGL which referenced memory outside of its lifetime. Since the memory location had no owner, vertices would still exist in Dev builds and everything would work fine, but in ReleaseSafe the application would run and just have nothing to render.

Since OpenGL was trying to read the memory, there was no panic from Zig, but it was a cool look into how the different build modes handle memory.

This is the commit where I fixed the issue: https://github.com/quot/donut/commit/8fff107e76278c4bf55007c...

by azakai24 minutes ago|

parent|

prev|

[-]

Zig does offer some amount of temporal memory safety.

Link: https://zig.guide/standard-library/allocators/

Text:

> The Zig standard library also has a general-purpose debug allocator. This is a safe allocator that can prevent double-free, use-after-free and can detect leaks.

For more detail, see:

https://github.com/ziglang/zig/issues/3180#issuecomment-5284...

by flohofwoe5 hours ago|

parent|

prev|

[-]

The DebugAllocator catches use-after-free (at least on page-level), but at the cost of never recycling memory addresses (e.g. it eats through the virtual address space).

https://ziglang.org/documentation/master/std/#src/std/heap/d...

For higher level code, "generation-counted index handles" might be the better solution to provide temporal runtime memory safety, not part of Zig the stdlib though.

Or even better: never use dynamic memory allocation and make all lifetimes 'static' :)

by landr0id5 hours ago|

parent|

[-]

>The DebugAllocator catches use-after-free (at least on page-level)

To clarify, is that to say that you have to use the `std.heap.page_allocator` as its backing allocator?

by 4 hours ago|

parent|

[-]

deleted

by dnautics4 hours ago|

parent|

prev|

[-]

as a reminder its a construct in the zig stdlib to take an arbitrary chunk of memory (could be stack, could be in the programs static space) and wrap it in an allocator interface and give that to any data structure that needs an allocator and use it as if it were just malloc/free, with a fixed memory limit and the correct memory errors.