On Tuesday, February 19, 2019 at 7:26:22 PM UTC+1, Ian Lance Taylor wrote: > > On Tue, Feb 19, 2019 at 9:34 AM Manlio Perillo <manlio....@gmail.com > <javascript:>> wrote: > > > > The Go language specification never mentions undefined behavior, however > > Ian Lance Taylor wrote, in [1], that: > > > > - if your program has a race condition, the behavior is undefined. > > > > [1] https://groups.google.com/forum/#!topic/golang-nuts/MB1QmhDd_Rk: >
> [...] Race conditions in general are covered by the Go > memory model at https://golang.org/ref/mem. That document explains > how you need to write your program to guarantee certain behavior. > [...] And > the program may panic or even simply crash. But I'm not comfortable > saying that the program is undefined in the sense of C, in which > anything at all may happen. > > I have read the Go memory model and found a sentence that seems to contradict what you said in https://golang.org/ref/mem#tmp_7: If the channel were buffered (e.g., c = make(chan int, 1)) then the program would not be guaranteed to print "hello, world". (It might print the empty string, crash, or do something else.) That's "something else" is quite dangerous. By the way, I think that the document should define stable HTML IDs. > [...] Thanks Manlio Perillo -- 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. For more options, visit https://groups.google.com/d/optout.
