![]() ![]() No run-time panic occurs in this case.įor unsigned integer values, the operations +, -, *, and << are computed modulo 2ⁿ upon overflow, where n is the bit width of the unsigned integer's type. Otherwise it is false and the value of v is computed as follows. The value of ok is true if the results of all arithmetic operators and conversions could be represented in their respective types. Yields an additional untyped boolean value. V, ok = expr v, ok := expr var v, ok = expr var v, ok T1 = expr If the result of any arithmetic operator or conversion to an integer type cannot be represented in the type, a run-time panic occurs.Īn expression consisting of arithmetic operators and / or conversions between integer types used in an assignment or initialization of the special form As a result, x > 1 is the same as x/2 but truncated towards negative infinity. Shifts behave as if the left operand is shifted n times by 1 for a shift count of n. The result of a logical shift is truncated to the bit width of the type: a logical shift never results in overflow. They implement arithmetic shifts if the left operand is a signed integer and logical shifts if it is an unsigned integer. The shift operators shift the left operand by the shift count specified by the right operand. Those alternatives could also be used to optimize out the overflow checks in inner-loop code when the programmer has already validated the inputs by some other means.Ĭoncretely, the proposed changes to the spec are: Integer operatorsįor two integer values x and y, the integer quotient q = x / y and remainder r = x % y satisfy the following relationships:Īs an exception to this rule, if the dividend x is the most negative value for the int type of x, the quotient q = x / -1 is equal to x (and r = 0). Implicit wrapping only for unsigned types ( uint32 and friends), since they're used for bit-manipulation code more often than the signed equivalents.Separate "integer mod 2ⁿ" types (requiring explicit conversions from ordinary integer types), perhaps named along the lines of int32wrap or int32mod."comma, ok" forms or "comma, carry" forms ( proposal: spec: extend comma-ok expressions to + - * / arithmetic #6815) that ignore overflow panics, analogous to how the "comma, ok" form of a type-assertion ignores the panic from a mismatched type.The checks can be omitted when the compiler can prove the result is within bounds, any new branches will be trivially predictable (they'll occupy some CPU resources in the branch-predictor but otherwise add little overhead), and in some cases the checks might be able to use bounds-check instructions or other hardware traps.įor the subset of programs and libraries that intentionally make use of wraparound, we could provide one of several alternatives: The potential performance impact of this proposal is similar to bounds-checking in general, and likely lower than using arbitrary-precision ints ( #19623). Even in the case where the unintended overflow is subsequently caught by a slice bounds check, reporting the error at the overflowing operation rather than the slice access would make the source of the bug easier to diagnose. For such programs, it would be clearer for overflow to cause a run-time panic (similar to dividing by zero) rather than silently wrapping around. In my experience, Go programs and libraries are often written assuming "reasonable inputs" and no overflow. And programs that use unsafe to access addresses with offsets are vulnerable to exactly the same overflow bugs as in C. Programs that marshal data-structures to be sent over the wire (such as protocol buffers) may send silently-corrupted data instead of returning errors as they ought to. For example, programs that make system calls may pass data structures into the kernel, bypassing Go's usual bounds checks. Go's bounds-checking on slices and arrays mitigates some of the harmful effects of overflow, but not all of them. Unexpected integer overflow can lead to serious bugs, including bugs in Go itself. I know this has been discussed before, but I didn't see a specific proposal filed for it yet and I think it's important.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |