Sorry, I think the code needs more explanation: A value of type Aligned[T,A] will allocate enough memory to contain one instance of T with alignment A. The fields pad and val will contain only garbage, they only exist for allocating enough memory and could as well be a byte array. To get the aligned value ot T, the Value() method must be called. It returns an aligned pointer inside the pad field and casts it to *T. See the playground example:
https://go.dev/play/p/qLvE5XY82h6 One more thing worth noting, by allowing only alignments larger than Go max alignment of 8 byte, it's ensured that T has still the alignment gurantees that Go itself expects. Mikk Margus schrieb am Mittwoch, 11. Juni 2025 um 18:07:18 UTC+2: > Oh, yeah, you're right, that does seem to be the intent. > > From what I know, and based on the documentation I linked before[1], > you can, at most, get 32-bit alignment on 32-bit platforms and 64-bit > alignment on 64-bit platforms with Go. At least with this approach. > For in-memory size/alignment purposes, an array type [N]T is equivalent > to just having N discrete attributes of type T on the struct. > > Which is to say, an array of 64 bytes does not increase your alignment > above 1 byte, and the best you'll get is an alignment of 8 bytes via > uint64, assuming you're on a 64-bit platform, and only 4 bytes on a > 32-bit platform. And [2]uint64 would not fare any better. > > Also, I appear to have accidentally veered off-list for this discussion > with Robert Engels, my apologies. > > > [1] https://go.dev/s/regabi > > On 6/11/25 17:00, Robert Engels wrote: > > I don’t think so - it a “64 BYTE aligned” to prevent false sharing - > > according to the original code. > > > >> On Jun 11, 2025, at 8:39 AM, Def Ceb <mikk....@gmail.com> wrote: > >> > >> > >> To get a n-bit-aligned pointer (where n is 16 or 64) to an arbitrary > >> value using generics, is it not? > >> > >> On Wed, Jun 11, 2025, 16:36 Robert Engels <ren...@ix.netcom.com > >> <mailto:ren...@ix.netcom.com>> wrote: > >> > >> It depends on what the OP is trying to align… eg is it to prevent > >> false sharing? > >> > >>> On Jun 11, 2025, at 8:14 AM, Def Ceb <mikk....@gmail.com > >>> <mailto:mikk....@gmail.com>> wrote: > >>> > >>> > >>> https://go.dev/s/regabi <https://go.dev/s/regabi> > >>> I believe this is true. The arrays of bytes would not enforce > >>> alignment any tighter than that of one byte. Replacing the > >>> aliases of Align16 and Align64 from byte arrays to uint16/uint64 > >>> would fix this. > >>> > >>> On Wed, Jun 11, 2025, 15:47 Robert Engels <ren...@ix.netcom.com > >>> <mailto:ren...@ix.netcom.com>> wrote: > >>> > >>> I don’t think the code works at all - at least not from an > >>> alignment perspective. For instance, assume T is one byte, > >>> and you use align 64, it is aligned on 65 byte boundaries. > >>> (This may not be fully correct need to read spec on structure > >>> member alignment - but the gist should be true) > >>> > >>>> On Jun 10, 2025, at 10:04 AM, Timur Celik <clk...@gmail.com > >>>> <mailto:clk...@gmail.com>> wrote: > >>>> > >>>> > >>>> Consider the following generic type, which ensures to be > >>>> large enough by allocating enough padding A and the to-be- > >>>> aligned type T: > >>>> > >>>> type Alignment interface { > >>>> Align16 | Align64 > >>>> } > >>>> type Align16 = [16]byte > >>>> type Align64 = [64]byte > >>>> > >>>> type Aligned[T any, A Alignment] struct { > >>>> pad A > >>>> val T > >>>> } > >>>> > >>>> func (p *Aligned[T, A]) Value() *T { > >>>> size := unsafe.Sizeof(*new(A)) > >>>> align := size - uintptr(unsafe.Pointer(&p.pad[0]))&(size-1) > >>>> return (*T)(unsafe.Pointer(&p.pad[align])) > >>>> } > >>>> > >>>> Under the assumption that T has no heap pointers, is this > >>>> safe? Or asked in another way, under which circumstances > >>>> would this break? > >>>> > >>>> -- > >>>> You received this message because you are subscribed to the > >>>> Google Groups "golang-nuts" group. > >>>> To unsubscribe from this group and stop receiving emails > >>>> from it, send an email to golang- > >>>> nuts+uns...@googlegroups.com <mailto:golang- > >>>> nuts+uns...@googlegroups.com>. > >>>> To view this discussion visit https://groups.google.com/d/ > >>>> msgid/golang-nuts/d00058ec- > >>>> cb9b-495f-807d-54397be94df2n%40googlegroups.com <https:// > >>>> groups.google.com/d/msgid/golang-nuts/d00058ec- > >>>> cb9b-495f-807d-54397be94df2n%40googlegroups.com? > >>>> utm_medium=email&utm_source=footer>. > >>> > >>> -- > >>> You received this message because you are subscribed to the > >>> Google Groups "golang-nuts" group. > >>> To unsubscribe from this group and stop receiving emails from > >>> it, send an email to golang-nuts...@googlegroups.com > >>> <mailto:golang-nuts...@googlegroups.com>. > >>> To view this discussion visit https://groups.google.com/d/ > >>> msgid/golang-nuts/D368E0E8- > >>> DE85-43D3-813E-60D359578DF8%40ix.netcom.com <https:// > >>> groups.google.com/d/msgid/golang-nuts/D368E0E8- > >>> DE85-43D3-813E-60D359578DF8%40ix.netcom.com? > >>> utm_medium=email&utm_source=footer>. > >>> > > -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. To view this discussion visit https://groups.google.com/d/msgid/golang-nuts/7b9b2598-f39b-4980-889c-36353c5aa34cn%40googlegroups.com.
