-
Notifications
You must be signed in to change notification settings - Fork 17.9k
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
cmd/compile: untyped int constant gives me an overflow error #66776
Comments
As the post mentions, untyped constants still have a default type through which it carries its value, the untyped part only means explicit type conversions aren't needed. Unlike many projects, the Go project does not use GitHub Issues for general discussion or asking questions. GitHub Issues are used for tracking bugs and proposals only. For questions please refer to https://github.com/golang/go/wiki/Questions |
As I wrote, overflow doesn't happen because of the default type, but it still happens, and it only happens in the case of untyped int constants, not untyped float constants.
It's not a "general discussion or questioning" even though it may seem that way at first glance (my mistake). As I wrote at the end, I expect the same behavior for untyped int constants and untyped float constants, so I suggest (propose) making the same limits ("overflow-free") for them. However, I'm not sure if the difference was made on purpose or if it's just a bug that nobody noticed until now. It is not clear to me why the issue was closed. |
See the implementation restriction in the spec at https://go.dev/ref/spec#Constants :
|
Go version
go version go1.22.0 linux/amd64
Output of
go env
in your module/workspace:What did you do?
As far as I know and understand, untyped numeric constants live, as Rob Pike says, in some kind of "ideal" world without any kind of limits (they are just like regular numbers from the real world).
So, I write the following two programs:
(1)
(2) -
c1
just got one more zero (that is, multiplied by 10)What did you see happen?
Running the first program went as I expected, it compiles. So, even though the given number is much larger than the default type (
int
), it is still untyped int constant that lives in "ideal" (real) word, thus the overflow of default type doesn't have any effect. All expected.However, the second program does not compile. It gives me
constant overflow (InvalidConstVal)
error.What did you expect to see?
I expect both programs to compile. Unfortunately, the second one doesn't compile due to overflow which, while unrelated to the default type, I don't expect to see in any form in the case of untyped numbers and this "ideal" world.
Additionally, if I add
.
at the end of the constant (c1
) and, by that, make it untyped float constants instead of untyped int constant, everything starts to work as I expected. In other words, no limits nor overflow appear (actually it does, but it is because the constant is too long; got the error messageexcessively long constant
- 10.000+ chars).Is this the expected behavior or a bug? Why does the untyped int constants have a limit, while an untyped float constants don't? Shouldn't untyped int constants also be unlimited and "overflow-free", that is, limited in the same way as untyped float constants (only by the number of characters)?
The text was updated successfully, but these errors were encountered: