code review 4639101: json: fix test if rand returns 0.

json: fix test if rand returns 0.

Fixes test when run with gccgo using optimization, which
changes the order of the calls to rand.

[iant, 2011-07-06 18:35:43]

Hello golang-dev@googlegroups.com (cc: golang-dev@googlegroups.com),

I'd like you to review this change to
https://go.googlecode.com/hg/

[gri, 2011-07-06 18:41:08]

LGTM

[gri, 2011-07-06 18:42:26]

FYI

http://codereview.appspot.com/4639101/diff/1/src/pkg/json/scanner_test.go
File src/pkg/json/scanner_test.go (right):

http://codereview.appspot.com/4639101/diff/1/src/pkg/json/scanner_test.go#new...
src/pkg/json/scanner_test.go:258: x := make([]interface{}, int(f))
s/int(f)/f/

[iant, 2011-07-06 20:01:02]

*** Submitted as http://code.google.com/p/go/source/detail?r=332835d5b61e ***

json: fix test if rand returns 0.

Fixes test when run with gccgo using optimization, which
changes the order of the calls to rand.

R=golang-dev, gri
CC=golang-dev
http://codereview.appspot.com/4639101

[rsc, 2011-07-11 06:34:51]

> Fixes test when run with gccgo using optimization, which
> changes the order of the calls to rand.

I'm looking for calls that could legally be ordered
and not seeing any.  Where are they hiding?

Russ

[iant2, 2011-07-11 16:54:14]

Russ Cox <rsc@golang.org> writes:

>> Fixes test when run with gccgo using optimization, which
>> changes the order of the calls to rand.
>
> I'm looking for calls that could legally be ordered
> and not seeing any.  Where are they hiding?

This is not completely proven, but it seemed plausible enough for me to
fix the code which looked wrong anyhow.  I think it's the overall order
in which the test functions are run that is different, not the specific
calls to rand.  The order of the tests doesn't matter, except to the
extent that it changes the calls to rand, and thus wound up with a zero
when it previously got a non-zero value.

Ian

[rsc, 2011-07-11 17:38:00]

> This is not completely proven, but it seemed plausible enough for me to
> fix the code which looked wrong anyhow.  I think it's the overall order
> in which the test functions are run that is different, not the specific
> calls to rand.  The order of the tests doesn't matter, except to the
> extent that it changes the calls to rand, and thus wound up with a zero
> when it previously got a non-zero value.

For what it's worth, the intent for gotest is to run all the tests
in the order in the file, so that if you put simple tests first
they get run first.

The order across files is not specified, but the only uses
of rand are in scanner_test.go.

Russ

[iant2, 2011-07-13 01:07:42]

Russ Cox <rsc@golang.org> writes:

>> This is not completely proven, but it seemed plausible enough for me to
>> fix the code which looked wrong anyhow.  I think it's the overall order
>> in which the test functions are run that is different, not the specific
>> calls to rand.  The order of the tests doesn't matter, except to the
>> extent that it changes the calls to rand, and thus wound up with a zero
>> when it previously got a non-zero value.
>
> For what it's worth, the intent for gotest is to run all the tests
> in the order in the file, so that if you put simple tests first
> they get run first.
>
> The order across files is not specified, but the only uses
> of rand are in scanner_test.go.

Yeah, I've noticed that in the past.  I patched the gccgo testsuite to
use gcc's -fno-toplevel-reorder option to emit functions in the order in
which they appear in the source file.

Ian