code review 5301056: big: (make) zero Rat values usable w/o initialization (issue 5301056)

[g...@golang.org]

Reviewers: rog,

Message:
Hello rogp...@gmail.com (cc: golan...@googlegroups.com),

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

Description:
big: (make) zero Rat values usable w/o initialization

- various cleanups along the way
- includes pending CL 5312044

Please review this at http://codereview.appspot.com/5301056/

Affected files:
M src/pkg/big/int.go
M src/pkg/big/int_test.go
M src/pkg/big/nat.go
M src/pkg/big/nat_test.go
M src/pkg/big/rat.go
M src/pkg/big/rat_test.go

[roger peppe]

[sorry for slow response - i've been abroad since wednesday]

LGTM, except that i think that nat{} should be written as nat(nil)
throughout, which will save an unnecessary allocation each time, AFAICS.

[roger peppe]

On 24 October 2011 12:48, roger peppe <rogp...@gmail.com> wrote:
> LGTM, except that i think that nat{} should be written as nat(nil)
> throughout, which will save an unnecessary allocation each time, AFAICS.

actually it occurs to me that an easy compiler optimisation would be to
use the same data pointer when making all zero-length slices,
thus avoiding the need for nat{} to do an allocation.

i can't off-hand think of anything this would break, as slices
aren't comparable, and there's no element to take the address of.
(Printf("%p") is one place non-unsafe code can observe it, but
i don't see that's necessarily a problem).