That is incorrect. In fact, there are a lot of incorrect statements in that article. The fact is: Intel-compatible CPUs loads 16-bit values (type Integer) into 32-bit or 64-bit registers. But it performs 16-bit arithmetic if indicated to do so by the machine language instructions.
Whether or not a computer language treats integers as 16-bit or 32-bit values (or even 64-bit values) is a property of the definition of the computer language.
As Rick demonstrated, obviously VBA uses 16-bit arithmetic for values that are implicitly or explicitly type Integer. We could write 1234# * 5678# in order to force VBA to do 32-bit (type Long) arithmetic. But 1234 * 5678 performs 16-bit arithmetic by default because each of 1234 and 5678 can be represented as 16-bit values.
In contrast, 1234 * 56789 does indeed perform 32-bit arithmetic, only becuase 56789 requires 32 bits (type Long) to be represented, and VBA coerces the left-hand expression (1234) to type Long automagically for the purpose of that arithmetic.
The flaw in the cited article (one of many) is that it chose 65535 to prove its point. Again, that value requires 32 bits to be represented.
I might add that the type coercion is performed based on the types of values of each pairwise operation, generally left-to-right, but subject to rules of operator percedence.
So 32767 + 123 + 45678 fails because 32767 + 123 is evaluated first with 16-bit arithmetic, resulting in overflow. On the other hand, 32767 + (123 + 45678) succeeds because 123 + 45678 is evaluated first with 32-bit arithmetic, which causes 32767 to be coerced to a 32-bit value for the second evaluation.
PS.... Generally, Rick is incorrect in stating that ``
modern computer will use the same amount of memory to store and Integer as a Long``. That really depends on the computer language
compiler or interpreter. I don't know about VBA per se. And of course, we are talking about the explicit type Integer and Long, not integers stored in type Variant variables.