Yeah, reading binary files in go with an mmap library and the whole file is based on offsets to point to other sections of the file. Damaged file or programming error and segfault.

▲

ncruces 4 days ago | parent [-]

How is that a data race? Also, you're using unsafe.

The post is about data races in safe Go leading to crashes or exploits, because things like "eface" (the tuple used to implement interfaces) and slices (again a tuple) are multi-word and thus impossible to update atomically.

This is not an issue in Java because such things always box behind a pointer.

	▲	debugnik 4 days ago \| parent [-]
		Note that C#'s Memory<T> (a slice) isn't boxed either, but it stays memory-safe under tearing: the resulting slice might have unintended bounds, but it will either be in-bounds or will throw an exception. This of course has some overhead, which is why you usually turn it into the cheaper, data race free Span<T>. Go could have the same safety and fix some of the overhead with compiler optimizations, they just don't want to take the trade-off.