3 ms·

i just read the doc and saw a page saying stdlib only targets x86 arch at the moment ? so no arm ?

by bsaul 3y ago

Daimanta 3y ago
According to https://ziglang.org/documentation/master/#Targets https://ziglang.org/documentation/master/#Targets the only fully supported targets are x86-64. This does not mean that the entire stdlib will only work on x86-64 but that specific functions that require information about the inner workings of an architecture is only guaranteed to work on x86-84. If you'd be interested in a hash function like CRC32 you can see in the source code that there is no dependency on arch specific functionality, which makes it likely that it will work fine on other (LE?) architectures. This is on a case-by-case basis at the moment though. The advice from the Zig community is to check the source code in case of doubt. I have always found the source to be accessible, so this hasn't been an issue for me.
kristoff_it 3y ago
nah that's absolutely not the case, we support a bunch of architectures (with varying degrees of support level). can you link to the page that said that? this is the most up to date support table for Zig: https://ziglang.org/download/0.10.0/release-notes.html#Support-Table https://ziglang.org/download/0.10.0/release-notes.html#Suppo...
- bsaul 3y ago
  sorry, i can't find the link back. Maybe it wasn't on the official site but from an old website. Another question i have : are there any kind of mechanism to ensure at least some kind of memory safety with regards to memory deallocation ? I'm honestly halfway to try and prototype some cross-platform lib for my mobile app using zig, but this part is really the one that bugs me. I'm fine with having no GC or no ARC like go or swift, (and i'm ok with no ownership mechanim like rust), but seeing absolutely nothing new since C on that side is both a surprise (since zig has improved other aspects like slices and fat pointers), and a worry.
  - kristoff_it 3y ago
    The GeneralPurposeAllocator will tell you about memory leaks and double frees in debug mode. Take a look at the example on the front page of ziglang.org. That said, the main feature that Zig offers for avoiding those mistakes are defer and errdefer, those really go a long way in avoiding mistakes, while also keeping things simple and explicit, which also helps avoid bugs. ArenaAllocator is another thing that helps with memory safety, depending on what you're doing. Finally, having to pass an allocator explicitly to all the things that need to allocate also helps with that: if you have an allocator to a struct when initing it, then you know you will most probably have to call its deinit method once you don't need it anymore.
  - 59nadir 3y ago
    > Another question i have : are there any kind of mechanism to ensure at least some kind of memory safety with regards to memory deallocation ? In general you probably need to learn about custom allocators and how different kinds can help you manage your memory. This applies to pretty much any lower-level language, but Odin, Zig, C++ and a few others have explicit support for this in their standard libraries.

i just read the doc and saw a page saying stdlib only targets x86 arch at the moment ? so no arm ?

by bsaul 3y ago

i just read the doc and saw a page saying stdlib only targets x86 arch at the moment ? so no arm ?

According to https://ziglang.org/documentation/master/#Targets https://ziglang.org/documentation/master/#Targets the only fully supported targets are x86-64. This does not mean that the entire stdlib will only work on x86-64 but that specific functions that require information about the inner workings of an architecture is only guaranteed to work on x86-84. If you'd be interested in a hash function like CRC32 you can see in the source code that there is no dependency on arch specific functionality, which makes it likely that it will work fine on other (LE?) architectures. This is on a case-by-case basis at the moment though. The advice from the Zig community is to check the source code in case of doubt. I have always found the source to be accessible, so this hasn't been an issue for me.

kristoff_it 3y ago

nah that's absolutely not the case, we support a bunch of architectures (with varying degrees of support level). can you link to the page that said that? this is the most up to date support table for Zig: https://ziglang.org/download/0.10.0/release-notes.html#Support-Table https://ziglang.org/download/0.10.0/release-notes.html#Suppo...

bsaul 3y ago
sorry, i can't find the link back. Maybe it wasn't on the official site but from an old website. Another question i have : are there any kind of mechanism to ensure at least some kind of memory safety with regards to memory deallocation ? I'm honestly halfway to try and prototype some cross-platform lib for my mobile app using zig, but this part is really the one that bugs me. I'm fine with having no GC or no ARC like go or swift, (and i'm ok with no ownership mechanim like rust), but seeing absolutely nothing new since C on that side is both a surprise (since zig has improved other aspects like slices and fat pointers), and a worry.
- kristoff_it 3y ago
  The GeneralPurposeAllocator will tell you about memory leaks and double frees in debug mode. Take a look at the example on the front page of ziglang.org. That said, the main feature that Zig offers for avoiding those mistakes are defer and errdefer, those really go a long way in avoiding mistakes, while also keeping things simple and explicit, which also helps avoid bugs. ArenaAllocator is another thing that helps with memory safety, depending on what you're doing. Finally, having to pass an allocator explicitly to all the things that need to allocate also helps with that: if you have an allocator to a struct when initing it, then you know you will most probably have to call its deinit method once you don't need it anymore.
- 59nadir 3y ago
  > Another question i have : are there any kind of mechanism to ensure at least some kind of memory safety with regards to memory deallocation ? In general you probably need to learn about custom allocators and how different kinds can help you manage your memory. This applies to pretty much any lower-level language, but Odin, Zig, C++ and a few others have explicit support for this in their standard libraries.