This is unsupported behavior and is not expected to work.
A netip.AddrPort is 16 bytes on 32-bit platforms. (12 for a netip.Addr, 2 for a uint16, 2 for padding.) The offset of af in your Addr is byte 14.
I'm not sure what the ultimate goal is here, but you'll need to find another way. Possibly duplicate the padding (add a _ uint16 after port in your Addr). But the real fix would be to not do unsafe stuff here. Why do you need to build your own data structures instead of just using netip.AddrPort/netip.Addr directly?

@randall77 isn't the size is 24 on 32-bit platforms? 20 for netip.Addr (2 uint64 + 1 pointer), 2 for a uint16, 2 for padding.

@database64128 your conversion violates the 1st rule of unsafe.Pointer conversion https://pkg.go.dev/unsafe#Pointer

Provided that T2 is no larger than T1 and that the two share an equivalent memory layout, this conversion allows reinterpreting data of one type as data of another type

Your Addr and netip.AddrPort have the same size, but do not have the same memory layout.

@cuonglm Yeah sorry, I can't do math.

Why do you need to build your own data structures instead of just using netip.AddrPort/netip.Addr directly?

This custom address type is used in places where the address is either a domain name or an IP. It used to consist of a netip.AddrPort and a string and take up 6 words on 64-bit platforms. I recently made the change to remove the string field and reuse the same space to store either a domain name or an IP. This reduced the size down to 4 words. The trick was documented in the comments of the type:

// For space efficiency, the IP address and the domain string share the same space.
// The [netip.Addr] is stored in its original layout.
// The domain string's data pointer is stored in the ip.z field.
// Its length is stored at the beginning of the structure.
// This is essentially an unsafe "enum".

your conversion violates the 1st rule of unsafe.Pointer conversion

the two share an equivalent memory layout

It's not clear to me what "equivalent" means. I think this needs to be clarified. And I still don't see how the memory layout is different. Can you elaborate on that?

Here's the memory layout of netip.AddrPort:

type uint128 struct {
	hi uint64
	lo uint64
}

type Addr struct {
	addr uint128
	z    *intern.Value
}

type AddrPort struct {
	ip   Addr
	port uint16
}

If you change my Addr type from:

type Addr struct {
	_    [0]func()
	addr netipAddrHeader
	port uint16
	af   addressFamily
}

to:

type Addr struct {
	_  [0]func()
	ap netip.AddrPort
	af addressFamily
}

It still has the same memory layout. And a pointer to an Addr value is equivalent to a pointer to its ap field.

It does not have the same memory layout. The padding is different.
A netip.AddrPort is, flattened, {uint64, uint64, pointer, uint16, 2 bytes of padding }
So your first Addr is {uint64, uint64, pointer, uint16, uint8, 1 byte of padding }
The second Addr is {uint64, uint64, pointer, uint16, 2 bytes of padding, uint8, 3 byte of padding }

Closing because this is not a bug in Go.

Thanks. I understand that this is undefined behavior. But still, I feel like this doesn't have to be like this way. The unaligned af byte won't get overwritten on amd64 and arm64. Is there any particular reason for 32-bit arm to not behave like its 64-bit counterparts?

The same behavior will happen on 64 bit for larger structs (add 2 more uint64 fields at the start).
The difference is that copies are done differently for "small" structs and "large" structs, and the structs involved are small on 64 bit but large on 32 bit (because a uint64 field has cost 1 on 64 bit but cost 2 on 32 bit).
"small" structs are copied field by field. "large" structs are copied with memcpy.