<p dir="auto">by <strong>tyapca7</strong>:</p>
<pre class="notranslate">What steps will reproduce the problem?
Install gomatrix.googlecode.com/hg/matrix
Install go-fn.googlecode.com/hg/fn
Get the branch 'tyapca7' from <a href="https://code.google.com/p/gostat" rel="nofollow">https://code.google.com/p/gostat</a>
cd gostat/stat
gomake install
cd bayes
gomake

What is the expected output?
gopack grc _obj/gostat.googlecode.com/hg/stat.a _go_.8

What do you see instead?
poisson.go:60: internal compiler error: unknown type
make: *** [_go_.8] Error 1

Which compiler are you using (5g, 6g, 8g, gccgo)?
8g

Which operating system are you using?
linux-386, kernel 2.6.35-22-generic

Which revision are you using?  (hg identify)
776b13062a2b (tyapca7) tip</pre>
<p dir="auto">by <strong><a href="mailto:justinas@justinas.me">justinas@justinas.me</a></strong>:</p>
<pre class="notranslate">What does 'go version' print?
go version go1.2.2 darwin/amd64

What steps reproduce the problem?
If possible, include a link to a program on play.golang.org.

1. Compare two byte slices with ConstantTimeCompare(), where the second slice is longer
and the first slice is a prefix of the second.

<a href="http://play.golang.org/p/XH0gRhdDTu" rel="nofollow">http://play.golang.org/p/XH0gRhdDTu</a>

What happened?

The function compares slices only up to the length of the first slice and thus gives a
false-positive.

What should have happened instead?

I understand that this is not the way this function is supposed to be used. However, the
behavior on this incorrect usage varies based on the order of the arguments. 

I think that panicking (due to out-of-range access), as the function does when the
*first* slice is longer, is a much better solution. Panic clearly indicates a mistake on
the programmer's part, whereas passing silently can go unnoticed for a long time and
even be exploited.

It's a simple fix to do, I think: instead of iterating up to len(x), iterate up to
max(len(x), len(y)).</pre>