Path: csiph.com!weretis.net!feeder6.news.weretis.net!feeder.usenetexpress.com!feeder-in1.iad1.usenetexpress.com!border1.nntp.dca1.giganews.com!nntp.giganews.com!news.iecc.com!.POSTED.news.iecc.com!nerds-end From: Ian Lance Taylor Newsgroups: comp.compilers Subject: Re: Optimization techniques and undefined behavior in Go Date: Mon, 6 May 2019 21:16:19 -0700 Organization: Compilers Central Lines: 17 Sender: news@iecc.com Approved: comp.compilers@iecc.com Message-ID: <19-05-055@comp.compilers> Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Injection-Info: gal.iecc.com; posting-host="news.iecc.com:2001:470:1f07:1126:0:676f:7373:6970"; logging-data="27987"; mail-complaints-to="abuse@iecc.com" Keywords: Go Posted-Date: 07 May 2019 18:48:32 EDT X-submission-address: compilers@iecc.com X-moderator-address: compilers-request@iecc.com X-FAQ-and-archives: http://compilers.iecc.com Xref: csiph.com comp.compilers:2290 Martin Ward writes: > There are many language in which all behaviour is defined: > for example, Go has no undefined behaviour. Some behaviour > may be "unspecified" (eg it could do X, or could do Y, > but cannot do anything else). (Setting aside the use of the "unsafe" package, of course.) We hope to get to that point, but it's not true today. The language spec is not clear on the effects of race conditions. With today's implementations you can set up a race condition that lets you change a slice pointer to anything at all, which effectively leads to undefined behavior even without using the "unsafe" package. See, e.g., https://research.swtch.com/gorace. Ian