You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The pre-1.18 compiler treats untyped constants of rune kind (such as 'a', '1' << 10, etc.) passed as arguments to the built-in functions print and println differently than other constants if those values overflow the 'rune' range.
Example, compiled using pre-1.18 compiler:
var_='1'<<32// constant 210453397504 overflows runeprintln('1'<<32) // no error
Example, compiled using 1.18 compiler:
var_='1'<<32// cannot use '1' << 32 (untyped rune constant 210453397504) as rune value in variable declaration (overflows)println('1'<<32) // cannot use '1' << 32 (untyped rune constant 210453397504) as rune value in argument to println (overflows)
The pre-1.18 compiler accepts an int64 value if an int32 value is not sufficient, rather than reporting an error as would be warranted by the usual assignment and parameter passing rules.
Proposal
The compiler should consistently apply parameter passing rules from now on, even for arguments to the "magic" built-in functions print and println.
For existing code that doesn't compile anymore there are a couple of work-arounds:
Use a conversion (e.g., int64('1' << 32)).
Compile using the 1.17 compiler by setting the -G=0 compiler flag. This doesn't require code changes.
Current implementations provide several built-in functions useful during bootstrapping. These functions are documented for completeness but are not guaranteed to stay in the language.
Thus, arguably a (non-temporary) correct program should not be relying on these functions in the first place. At the very least we should be in the position to make this minor adjustments.
Implementation
If the proposal is accepted, nothing needs to be done; this is already the new behavior of the compiler.
If the proposal is not accepted, the compiler needs to be adjusted such that untyped rune constant arguments to print and println are treated as int64 values if they overflow as rune (i.e., int32) values.
The text was updated successfully, but these errors were encountered:
This is spec-compatible, and it is also compatible with go vet.
(go vet would not have succeeded on code that is newly rejected here.)
Since there is no spec change, we don't really need a proposal here,
but we should be ready to implement the old behavior
if there are significant problems during the beta/rc period.
Leaving open to document in release notes.
rsc
changed the title
proposal: cmd/compile: consistently report overflow for untyped constant arguments of to print/println
cmd/compile: consistently report overflow for untyped constant arguments of to print/println
Nov 3, 2021
griesemer
changed the title
cmd/compile: consistently report overflow for untyped constant arguments of to print/println
cmd/compile: consistently report overflow for untyped constant arguments of to print/println - needs release notes
Nov 3, 2021
Problem
The pre-1.18 compiler treats untyped constants of rune kind (such as
'a'
,'1' << 10
, etc.) passed as arguments to the built-in functionsprint
andprintln
differently than other constants if those values overflow the 'rune' range.Example, compiled using pre-1.18 compiler:
Example, compiled using 1.18 compiler:
The pre-1.18 compiler accepts an
int64
value if anint32
value is not sufficient, rather than reporting an error as would be warranted by the usual assignment and parameter passing rules.Proposal
The compiler should consistently apply parameter passing rules from now on, even for arguments to the "magic" built-in functions
print
andprintln
.For existing code that doesn't compile anymore there are a couple of work-arounds:
int64('1' << 32)
).Per the spec:
Thus, arguably a (non-temporary) correct program should not be relying on these functions in the first place. At the very least we should be in the position to make this minor adjustments.
Implementation
If the proposal is accepted, nothing needs to be done; this is already the new behavior of the compiler.
If the proposal is not accepted, the compiler needs to be adjusted such that untyped rune constant arguments to
print
andprintln
are treated asint64
values if they overflow asrune
(i.e.,int32
) values.The text was updated successfully, but these errors were encountered: