On go's compatibility promise, and other lies

<p>Go 1.4&#39;s release doc says</p> <blockquote> <p>As always, Go 1.4 keeps the promise of compatibility, and almost everything will continue to compile and run without change when moved to 1.4.</p> </blockquote> <p>Note “almost”. Excluded from that promise is the <code>syscall</code> package, allegedly because operating systems change. In practice, 1.4 removed workable implementations of <code>Setgid</code> and <code>Setsid</code>. If you use those syscalls, and things fail mysteriously in 1.4, you need to copy the 1.3 implementation.</p> <p>See issue 1435 for details, if you want. I&#39;ll be sulking in the corner.</p> <hr/>**评论：**<br/><br/>davecheney: <pre><p>Setgid and Setuid never worked on linux, but it just looked like it did. I changed those functions to return an indication that they didn&#39;t work as intended on linux for Go 1.4. Here is the change</p> <p><a href="https://codereview.appspot.com/106170043" rel="nofollow">https://codereview.appspot.com/106170043</a></p> <p>There is also an explanation in the source directly above the code</p> <p>See <a href="http://golang.org/src/syscall/syscall_linux.go#L848" rel="nofollow">http://golang.org/src/syscall/syscall_linux.go#L848</a></p></pre>chipaca: <pre><p>As I said elsewhere, them applying to the current “os thread” only is surprising, but workable if you know what you&#39;re doing (and this is one of the few places where linux having processes and threads be the same thing is inconvenient, so I&#39;m not complaining about that). Them stopping working was another surprise that took us some time to hunt down (unit tests don&#39;t run with root, so that particular code path only comes up in integration tests).</p> <p>Granted it&#39;s mentioned in the “minor changes” (I might argue that purposely changing the behaviour part of the standard library is not “minor”), and the comment in syscall_linux was what got us to the workaround (which is to include go 1.3&#39;s setuid and setgid in our code), so thank you for that.</p> <p>The code in question is snappy&#39;s unpacker, fwiw. <a href="http://bazaar.launchpad.net/%7Esnappy-dev/snappy/snappy/view/head:/cmd/snappy/cmd_internal_unpack.go#L95" rel="nofollow">http://bazaar.launchpad.net/~snappy-dev/snappy/snappy/view/head:/cmd/snappy/cmd_internal_unpack.go#L95</a></p></pre>dgryski: <pre><p>Code using setgid/setsid and friends were always broken. Making a wrong program worse is no sin. The same thing will happen with 1.5&#39;s change GOMAXPROCS=NumCPU(). Race conditions that were hidden by the fact they were on a single thread will become more apparent. But the code was already broken, since the compiler only generates correct code in the face of no data races.</p></pre>chipaca: <pre><p>All it takes to “unbreak” code is a call to <code>runtime.LockOSThread</code>.</p></pre>dgryski: <pre><p>Reading the comments in that issue it appears that <code>runtime.LockOSThread</code> is not a universally applicable workaround.</p></pre>chipaca: <pre><p><code>Setuid()</code> et al apply to the current os thread process only, because it naïvely calls the setuid syscall without thought of how users would expect it to behave like the glibc <code>setuid(2)</code> wrapper. And that&#39;s a bug, sure, it makes things harder. But with 1.4 even that was removed, so once again we have code that works in one version of Go, failing in the next one. This is the second time I&#39;ve wasted time on this kind of things, and it gets tiring.</p> <p>I hate to think how things will break when we <em>don&#39;t</em> have a compatibility “promise”.</p></pre>4ad: <pre><p>No, we don&#39;t have code that <em>works in one version of Go</em>, your program was always broken.</p></pre>chipaca: <pre><p>I don&#39;t believe it&#39;s broken. Could you point out how my program is broken please?</p></pre>jeffmetal: <pre><p>I didn&#39;t think the syscall package was part of the compatibility promise <a href="https://golang.org/doc/go1compat" rel="nofollow">https://golang.org/doc/go1compat</a> look under operating systems.</p></pre>