undo the math crc param optimization that now causes the footgun warning when you import math. + doc fix about arithmetic expressions

This commit is contained in:
Irmen de Jong
2025-10-14 00:30:20 +02:00
parent 68066acdec
commit f5ce744748
7 changed files with 19 additions and 7 deletions
+6 -4
View File
@@ -935,14 +935,15 @@ within parentheses will be evaluated first. So ``(4 + 8) * 2`` is 24 and not 20,
and ``(true or false) and false`` is false instead of true.
.. attention::
**calculations keep their datatype even if the target variable is larger:**
**calculations keep their datatype even if the target variable is larger (unless it's a constant):**
When you do calculations on a BYTE type, the result will remain a BYTE.
When you do calculations on a WORD type, the result will remain a WORD.
For instance::
byte b = 44
; for the sake of this example: make sure this is not optimized away as a constant
byte @shared b = 44
word w = b*55 ; the result will be 116! (even though the target variable is a word)
w *= 999 ; the result will be -15188 (the multiplication stays within a word, but overflows)
w *= 999 ; the result will be -15188 (stays within a word, but overflows)
*The compiler does NOT warn about this!* It's doing this for
performance reasons - so you won't get sudden 16 bit (or even float)
@@ -950,7 +951,8 @@ and ``(true or false) and false`` is false instead of true.
If you do need the extended resulting value, cast at least one of the
operands explicitly to the larger datatype. For example::
byte b = 44
; for the sake of this example: make sure this is not optimized away as a constant
byte @shared b = 44
w = (b as word)*55
w = b*(55 as word)