On Tuesday, February 19, 2019 at 9:36:10 PM UTC+1, Ian Lance Taylor wrote: > > On Tue, Feb 19, 2019 at 11:06 AM Manlio Perillo > <manlio....@gmail.com <javascript:>> wrote: > > [...]
> 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 > > [...] > > > > 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. > It seems this section was added in C11. In the Committee Draft for C99 it is not present. > 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. > > Yes, I understand. > [...] > > 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." > > I wrote "prejudice" since I was not aware of the phrase: "A correct program may not contain undefined behavior". Now I agree with you about not wanting to use undefined behavior in Go. Out of curiosity (to find if ISO C is the only one that use undefined behavior in that way) I checked other standards. The ISO Ruby standard (https://www.ipa.go.jp/files/000011432.pdf) don't use undefined behavior, but: implementation-defined: Possibly differing between implementations, but defined for every implementation. unspecified: Possibly differing between implementations, and not necessarily defined for any particular implementation. The ECMA Script *do* use undefined behavior: https://stackoverflow.com/questions/14863430/does-javascript-have-undefined-behaviour The text used is "behavior is undefined", but it seems it is never defined. The ANSI Common Lisp says: "When an error goes undetected, the effects can be implementation-dependent, implementation-defined, unspecified, or undefined." unspecified: This means that the consequences are unpredictable but harmless. Implementations are permitted to specify the consequences of this situation undefined: This means that the consequences are unpredictable. The consequences may range from harmless to fatal. The Go specification do use both implementation-dependent and implementation-defined, and I assumed it was a typo. But what is the difference between implementation-dependent and implementation-defined? I think that the Go specification should have a glossary. 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.
