This is not necessarily due to races. You can have this exact situation
occurring in single threaded code. I don't think any mention of race
issues was made here.
On Sun, 2019-10-27 at 08:53 +, roger peppe wrote:
> On Sun, 27 Oct 2019, 00:04 Gert, wrote:
>
> > I believe it's going to be to h
>> I think it only catches concurrent access to the same address, so not sure
>> if it catches everything.
>
>
> If two things aren't writing concurrently to the same address, what's the
> problem?
I took that to mean 'things may be updating concurrently at different
addresses inside an array ba
On Sun, 27 Oct 2019, 12:33 Gert, wrote:
>
> On Sunday, October 27, 2019 at 9:54:29 AM UTC+1, rog wrote:
>>
>>
>> On Sun, 27 Oct 2019, 00:04 Gert, wrote:
>>
>>> I believe it's going to be to hard to write a go vet analyser that could
>>> warn to detect unintended state change on a array from two
On Sunday, October 27, 2019 at 9:54:29 AM UTC+1, rog wrote:
>
>
> On Sun, 27 Oct 2019, 00:04 Gert, > wrote:
>
>> I believe it's going to be to hard to write a go vet analyser that could
>> warn to detect unintended state change on a array from two different
>> pointers.
>>
>
> Isn't that why we
Today I learned a fellow programmer did just that! His name is Everton
Marques.
https://github.com/udhos/basgo
On Sat, Oct 26, 2019 at 12:33 PM Robert Engels
wrote:
> Why not generate Go?
>
>
--
You received this message because you are subscribed to the Google Groups
"golang-nuts" group.
To
On Sun, 27 Oct 2019, 00:04 Gert, wrote:
> I believe it's going to be to hard to write a go vet analyser that could
> warn to detect unintended state change on a array from two different
> pointers.
>
Isn't that why we have the race detector?
--
> You received this message because you are subsc
