Go: proposal: spec: disallow assigning >32bit untyped constant to variable of type int

[bradfitz]

I propose that the Go language and implementations be changed to reject a constant assignment to a variable of type int (or uint) if the constant would overflow a 32-bit int (or uint), regardless of the size of int on the current GOOS.

That is, on amd64, this would be rejected:

const MaxInt64 = 1<<63 - 1

var x int = MaxInt64

Currently that passes on 64-bit platforms but fails when people cross-compile it to Raspberry Pis or run it on the playground (https://play.golang.org/p/4PK8z_WBKi).

This bites people like in https://github.com/GoogleCloudPlatform/google-cloud-go/issues/648 where it lurks unnoticed by users & continous builds for a long time, until somebody builds the code for the increasingly rare 32-bit machines.

/cc @griesemer

[mvdan]

Have you thought about making this a go vet error instead? Or is "breaking" these programs on 64-bit acceptable, given that they're not valid programs on all architectures?

[cznic]

I don't think the lack of proper release testing of some projects for more platforms/architectures justifies bending the language to "solve" the problem. (And I was bitten this way by my own code more than once.)

[bradfitz]

@mvdan, a vet error would be a good first step (especially if #18084 happens), but I still consider these invalid programs in all cases.

@cznic, I would normally agree with you on that (that the answer is testing), but in this case I think the language just shouldn't permit it in the first place. I don't think it should be possible to write a portable Go program (no syscall, unsafe, etc) program that runs on some machines but not others.

[rsc]

Based on discussion with @bradfitz, this is only about assigning an untyped constant to an int/uint/uintptr. The following are OK because the constants are typed:

const X int = 1<<63-1
var x int = X

var y uintptr = ^uintptr(0)

[davecheney]

I'm not in favour of this proposal, the situations it addresses are pretty
rare.

However if you're serious about this, what about this counter proposal:

Drop support for typed integer constants if the type is machine size
dependant.

That is, rather the clamping into/uint to 31/32 bits ... If someone does
want to make their numeric constant typed, they have to be precise about
how many bits they need.

Thoughts?

Dave

On Fri, 9 Jun 2017, 03:15 Brad Fitzpatrick [e-mail] wrote:

I propose that the Go language and implementations be changed to reject a
constant assignment to a variable of type int (or uint) if the constant
would overflow a 32-bit int (or uint), regardless of the size of int on
the current GOOS.

That is, on amd64, this would be rejected:

const MaxInt64 = 1<<63 - 1
var x int = MaxInt64

Currently that passes on 64-bit platforms but fails when people
cross-compile it to Raspberry Pis or run it on the playground (
https://play.golang.org/p/4PK8z_WBKi).

This bites people like in GoogleCloudPlatform/google-cloud-go#648
https://github.com/GoogleCloudPlatform/google-cloud-go/issues/648 where
it lurks unnoticed by users & continous builds for a long time, until
somebody builds the code for the increasingly rare 32-bit machines.

/cc @griesemer https://github.com/griesemer

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/golang/go/issues/20616, or mute the thread
https://github.com/notifications/unsubscribe-auth/AAAcAwPxGS2A0jIynov0DfsqL3BsXfaFks5sCCwZgaJpZM4N0Xpc
.

[rsc]

@davecheney, so then I can't write ^uintptr(0) at all?

[davecheney]

I didn't say it was a _good_ counter proposal :) But I posit that it's a
little more consistent than making const x int limited to a number that is
smaller than var x int.

On Tue, Jun 13, 2017 at 11:53 PM, Russ Cox [e-mail] wrote:

@davecheney https://github.com/davecheney, so then I can't write
^uintptr(0) at all?

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/golang/go/issues/20616#issuecomment-308123054, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AAAcA1fQH9mTCDpUaWgvPsuzCAHhGxf8ks5sDpRogaJpZM4N0Xpc
.

[ianlancetaylor]

It's currently confusing in Go that the expression uint(-1) does not compile. This proposal would seem to extend that to saying that the expression int64(0x100000000) would not compile. Russ's comment above suggests that we only want to give an error on an attempt to assign an untyped constant to a variable of type int, but that isn't something we have in the language right now, so that would need to be more clearly specified.

[drakmaniso]

As long as int is part of the language, it will be a potential failure point for cross-platform development. This proposal would solve compile-time failures, but leave the much harder to spot (and to test for) run-time bugs (i.e. when an int variable suddenly overflows). Note that 32 bit platforms are still the norm for embedded development, and TinyGo has shown that Go has a good potential there.

IMHO the right solution would be to remove int altogether, and use int32 as the default integer type. This is the approach taken by Rust. (see RFC 212)

I don't think there is any good reason to choose int64 as the default, even on 64 bit platforms: 32 bit integers already provide a reasonable range of numbers, are most of the time faster, and safe to convert to the default float type.

Another solution would be proposal #19623

[beoran]

Yes, I think this proposal only plasters over the problem, so I am not in favor of it. #19623 would probably be the better solution.