<p>I've been having some fun with <a href="http://codegolf.stackexchange.com/questions/61115/make-your-language-unusable/">this hilarious CodeGolf stack exchange question</a>. Read the challenge for a full and clear specification. Last year, the user Cat posted this Go answer (which I've edited for simplicity):</p>
<pre><code>package main
func main() {
const (
append = iota
cap; close; complex; copy
delete
imag
len
make
new
panic; print; println
real
recover
bool; byte
complex64; complex128
error
float32; float64
int; int8; int16; int32; int64
rune
string
uint; uint8; uint16; uint32; uint64; uintptr
true
false
nil
iota = 0
)
// User code goes here
}
</code></pre>
<p>From here on, code samples will go under the <code>// User code goes here</code> line unless otherwise indicated.</p>
<p>Imports can only be done at the top of the file, which means we can't access <code>fmt</code>, <code>os.Args</code>, <code>syscall</code>, or <code>flag</code>. We've erased <code>panic</code>, <code>print</code>, and <code>println</code>, which would allow us to affect the output in at least some way.</p>
<p>However, on seeing this answer the thought occurred to me that you don't need to call <code>panic</code> directly. You can just do something to cause a panic. So we can create a primality test based on panicking or not panicking:</p>
<pre><code>n := 37
for i := 2; i < n; i++ {
if n % i == 0 {
c := []struct{}{}
_ = c[1]
}
}
</code></pre>
<p>This will panic if <code>n</code> is composite and output nothing if it is prime. Luckily, we can plug that leak by adding this code to the top of <code>main</code>:</p>
<pre><code>defer func() {
_ = recover()
}
</code></pre>
<p>Now any panics we create will be absorbed.</p>
<p>That is, any panics in the <code>main</code> goroutine! Go's concurrency features allow us to bypass this block again by wrapping the code in a <code>go</code> statement:</p>
<pre><code>go func() {
n := 37
for i := 2; i < n; i++ {
if n % i == 0 {
c := []struct{}{}
_ = c[1]
}
}
}()
var c chan interface{}
<-c
</code></pre>
<p>Now the program deadlocks on primes and panics on non-primes.</p>
<p>So how can this leak be plugged, and Go made unusable? The only thing I could think of was using the <code>runtime</code> package to restrict the number of goroutines, but there appears to be no such facility, so I'm out of ideas.</p>
<hr/>**评论：**<br/><br/>tclineks: <pre><p>deargodwhy</p></pre>joushou: <pre><p>Now returns cleanly on success, and panics on failure.</p>
<pre><code>fail := func() {
go func() {
_ = []struct{}{}[1]
}()
var c chan interface{}
<-c
}
n := 37
for i := 2; i < n; i++ {
if n%i == 0 {
fail()
}
}
</code></pre></pre>Partageons: <pre><p>Since you're the only one who's offered any help, I'm getting closer. Here's what I have now: <a href="https://play.golang.org/p/9DLXU2gfMC" rel="nofollow">https://play.golang.org/p/9DLXU2gfMC</a> Despite <code>main</code> and the infinite loop goroutine being locked to the two available OS threads, the user can still create a new goroutine and block main to panic within that goroutine.</p></pre>DeedleFake: <pre><p>I'm not too clear on a lot of the internals of the runtime, but how about the following:</p>
<pre><code>runtime.GOMAXPROCS(1)
runtime.LockOSThread()
</code></pre></pre>Partageons: <pre><p>I've tried that. Somehow the user can break out by blocking the <code>main</code> goroutine. <a href="https://play.golang.org/p/Gm4QabOFl_" rel="nofollow">https://play.golang.org/p/Gm4QabOFl_</a></p></pre>metamatic: <pre><p>It's hard to beat Smalltalk, where you can simply redefine true to be false and watch everything crash.</p></pre>brogrammingsins: <pre><p>What's the point behind this? Why would it ever be useful?</p></pre>Carpetsmoker: <pre><p>Code golf are more like puzzles than anything else (i.e. entertainment). Some people seem to enjoy that sort of stuff...</p>
<p>Still better than football :-)</p></pre>hukiki: <pre><p>haha this is awesome. I love the JS version of the answer in the original link. Thanks OP. </p></pre>
