I want to re-emphasise that both of these examples violate the allowed usages of unsafe.Pointer defined by gc. So I would argue that, yes, its expectation is reasonable, because it explicitly told you not to create this situation.
If you can construct a program that does not violate the unsafe.Pointer rules and yet behaves unexpectedly, the question might be more ambiguous. On Thu 20. Jun 2024 at 16:18, Oliver Eikemeier <eikeme...@fillmore-labs.com> wrote: > Thanks for that example. > > The issue is that you and I have constructed aliased variables that the > optimizer assumes are not aliased. Therefore the “false” on comparison, > which also happens with pointers to zero-sized variables, but is much more > common in the latter case. > > This is interesting. I’m not enough of a compiler buff to say that this > assumption is reasonable - Go is 14 years old, so it seems to work - but > obviously one can write code where it is false, the “zero-sized pointers” > being the most prominent example. Anyone has a pointer to the alias > analysis design of the Go compiler? > > Am 20.06.2024 um 15:57 schrieb Axel Wagner <axel.wagner...@googlemail.com > >: > > I don't believe the issue in this case really is to do with zero-sized > variables. Here is an example with the same output, not involving any > zero-sized variables: > https://go.dev/play/p/JzbwbVqBR0k > The issue is that you treat a `*struct{}` as an `*int` - that is, you > explicitly obtain a pointer to invalid memory - and then expect that to > have any reasonable behaviour. > > > -- 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 on the web visit https://groups.google.com/d/msgid/golang-nuts/CAEkBMfGqXfeeU32z1tetauvH91u4iZSocKd3j2127tiSqGY2QQ%40mail.gmail.com.
