On Tue, Feb 19, 2019 at 11:06 AM Manlio Perillo <manlio.peri...@gmail.com> wrote: > > 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> 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"
The key section is the one on "Conformance," which in C11 is section 4. A correct program may not contain undefined behavior. C compiler writers have interpreted this as license to assume that a program contains no undefined behavior. This then leads to optimizations that many programmers find to be surprising. I wrote this about a bit at https://www.airs.com/blog/archives/120 . When I say that I'm not comfortable with Go having undefined behavior in the C sense, that is what I mean: I don't think that Go compilers should optimize programs on the basis that they do not act in some undefined manner. I think you understand that. >> 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. I'm not sure what you mean by "prejudice" here. You're right about the source of the feeling but that makes it a "judgement," not a "prejudice." Ian -- 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.
