New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
proposal: spec: disallow assigning >32bit untyped constant to variable of type int #20616
Comments
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? |
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.) |
@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. |
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:
|
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 ***@***.***> 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 googleapis/google-cloud-go#648
<googleapis/google-cloud-go#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
<#20616>, or mute the thread
<https://github.com/notifications/unsubscribe-auth/AAAcAwPxGS2A0jIynov0DfsqL3BsXfaFks5sCCwZgaJpZM4N0Xpc>
.
|
@davecheney, so then I can't write ^uintptr(0) at all? |
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 ***@***.***> 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
<#20616 (comment)>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/AAAcA1fQH9mTCDpUaWgvPsuzCAHhGxf8ks5sDpRogaJpZM4N0Xpc>
.
|
It's currently confusing in Go that the expression |
As long as IMHO the right solution would be to remove I don't think there is any good reason to choose Another solution would be proposal #19623 |
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. |
I propose that the Go language and implementations be changed to reject a constant assignment to a variable of type
int
(oruint
) if the constant would overflow a 32-bitint
(oruint
), regardless of the size ofint
on the current GOOS.That is, on
amd64
, this would be rejected: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 googleapis/google-cloud-go#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
The text was updated successfully, but these errors were encountered: