@bagder is there an open source POSIX test suite? The Open Group has one, but it isn't open source, so I don't know whether it has a test case for this situation, or if it doesn't, then how to submit one for this bug.
@bagder@muslhttps://www.rfc-editor.org/rfc/rfc4291.html#section-2.5.5.1 says those addresses are deprecated, and "new or updated implementations are not required to support", also RFC5156 says "these addresses are deprecated and should not appear on the public internet". The `::ffff:ipv4` form does work with musl though (and this form isn't deprecated). I don't know why they deprecated the nicer looking one... Although musl does fail one of sortix's https://gitlab.com/sortix/os-test/-/blob/main/basic/arpa_inet/inet_ntop.c the '::89ab..' has some extra '0:0:'. Thought about adding a new test case there, but since this form is deprecated it probably doesn't matter what the output looks like.
@david_chisnall probably also run a mix of hypervisors (not just different versions, completely different ones), and a mix of CPU vendors (multiple hypervisors don't help when they're all affected by the same Intel or AMD bug) and a mix of CPU architectures. Although that still doesn't protect you against bugs that affect all or most architectures (like some of the side-channel attacks). If you run an unpopular OS, hypervisor, or architecture you may have some protection against widely used exploits until your OS/hypervisor/architecture becomes widely used and targeted by exploits. Having said that if we ever get to live in a CHERI monoculture that wouldn't be so bad, it'd significantly raise the complexity and reduce the likelihood of attacks :)
This was from ~17 years ago, and TBH I'm not convinced the "fix" avoids UB completely, but I assume someone would've found a unit test failure by now, but I see the code still looks the same now. Perhaps the only way to really avoid UB there is to use `memcpy`, and hope the compiler will be smart enough to optimize it away.