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: > > Although I did say that, I want to clarify that I'm not really > comfortable with saying that Go ever has undefined behavior in the > sense that C does.
>From http://www.open-std.org/jtc1/sc22/WG14/www/docs/n1256.pdf (hoping it is legal to copy and paste the text): undefined behavior: behavior, upon use of a nonportable or erroneous program construct or of erroneous data, for which this International Standard imposes no requirements NOTE: Possible undefined behavior ranges from ignoring the situation completely with unpredictable results, to behaving during translation or program execution in a documented manner characteristic of the environment (with or without the issuance of a diagnostic message), to terminating a translation or execution (with the issuance of a diagnostic message). EXAMPLE: An example of undefined behavior is the behavior on integer overflow I don't think there is a problem with this definition, and a race condition is well described (IMHO) by the note: "ignoring the situation completely with unpredictable results" 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. If > you don't write your program that way, the results are unspecified. > However, I don't think they are undefined in the sense of C. For > example, if two different goroutines write to the same global variable > then we don't know which value that variable will get, and we don't > necessarily know for sure that it will get one value or the other--it > may in some cases get some peculiar combination of the values. 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 can not comment since I'm not a compiler expert. But I suspect that it is a prejudice caused by how C compiler writers abused the definition of undefined behavior to optimize the code. > In particular I'm not comfortable saying that a Go compiler may > optimize in the way that a C compiler may, by assuming that undefined > behavior may never happen. But, AFAIK, the C standard **never** says that undefined behavior may never happen. > I'm not sure that Go will ever have > undefined behavior in that sense. > > I agree. The gc compiler, if I remember correctly, do not have optimization flags in order to ensure the reproducibility of testing/development/production environments This is one of many things I like about Go, and I think that Go will be remembered in future for these features (and formatting tools inspired by gofmt are becoming standards). P.S.: I hope the text is well formatted since I had to manually wrap it. 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.
