I'm allocating an opaque type with known size in bytes. How would I make sure it aligns properly? I guess it's guaranteed to be aligned at page boundary with the page allocator, but can you control the alignment in other allocators?
#Allocators and data alignment
fast idol
fast idol
oh nice!
viral ridge
actually I have no idea what the documentation is smoking, unless there was just a change to how alignedAlloc works
the signature should be pub fn alignedAlloc(self: Allocator, comptime T: type, comptime alignment: ?u29, n: usize)
viral ridge
yeah, looks to just be a bug with autodoc
fast idol
Reopening it to say - is there any way to use it with runtime known alignment?
winged garnet
Just align to the max it could be
fast idol
Hmm, it returns an aligned slice, and in align(x) x has to be known at comptime, but it seems like a pretty useless feature
winged garnet
It's a very useful feature for optimizations
fast idol
Just align to the max it could be
I was thinking that I could compare it to the comptime alignment, and throw an error if it's bigger
winged garnet
Where do you get the alignment from?
fast idol
Where do you get the alignment from?
from a dll, which has a global with an @alignOf of the struct
winged garnet
Well, unless it's using any vector types you can safely assume the alignment is <=8
If it is using vector types you can probably assume it's <=64
If you really want runtime alignment you can use rawAlloc but that's kinda an internal function and it requires some extra work to use
fast idol
ideally, I wouldn't want to assume anything and have a smallest possible alignment at runtime, but I'm going to do what you say
fast idol
If you really want runtime alignment you can use rawAlloc but that's kinda an in...
I also want to use ArrayListAligned, so that's probably out of question
maybe the align(x) feature could have runtime or indeterminate x
as from what I see, the only reason the alignment in alignedAlloc is comptime, is because it returns []align(alignment orelse @alignOf(T)) T
distant lantern
That becomes a bit weird because it means pointer types have part of the type being only runtime-known which also means pointers need extra associated data and stuff so it can't really work
fast idol
so maybe I could construct the type of the ArrayListAligned at runtime somehow?
distant lantern
No, types cannot exist at runtime
The alignment here has to be comptime-known
Hence squirl's suggestion of just using the max alignment
fast idol
That becomes a bit weird because it means pointer types have part of the type be...
oh right, but what about indeterminate alloc()?
distant lantern
That returns a byte slice which is by default align(1) so it makes no alignment guarantees
fast idol
oh, i meant align(), sorry
distant lantern
wdym?
fast idol
that the pointer would have absolutely no guarantees about alignment at comptime
distant lantern
That's just align(1)
(since any pointer is clearly 1 byte aligned, i.e. every address is a multiple of 1)
fast idol
right
then there could be an allocRuntimeAligned function which returns a slice with align(1), but is really the runtime alignment
(or align(T) I guess)
distant lantern
If you really want runtime alignment you can use rawAlloc but that's kinda an in...
This is your only real option for runtime-known alignment atm. Aligning to the max is better for optimization and will at worst use a few bytes more memory so I heavily encourage doing that
fast idol
just asking if it would make sense, but yeah, I will just use 8 alignment and for extra safety check if the @alignOf from the dll is higher or lower