It doesn’t need to be complicated and slow at all. Java and C# designed interfaces without those problems (much earlier than Go did). The problem with slices is that Go trusts the length. So a race could overwrite ptr to point to a smaller alloc, allowing for OOB R/W.
-
-
Specifically: Thread A: slice = bigArray[0:100] slice = smallArray[0:10] Thread B: slice[20] = 12345 A: slice.ptr = &smallArray B: Read slice.ptr B: Read slice.len B: Bounds check, 20 < 100 so OK B: Write 12345 /* OOB */ A: Write 10 to slice.len
-
I understand this, but I don't see much value in addressing it.
- 2 more replies
New conversation -
-
-
But yet again, that would be a race condition in your code and that could corrupt other parts of your logic. If you have a race condition at any level you lose soundness and you can't create a race free language.
-
I think there are many things a language cannot take care of and there is a limited amount of time you can invest at any time. It is all about tradeoffs, Go decided that races would have been possible and decided to not invest in limiting their effects.
- 2 more replies
New conversation -
Loading seems to be taking a while.
Twitter may be over capacity or experiencing a momentary hiccup. Try again or visit Twitter Status for more information.