The ATtiny85 is an 8 bit MCU. It has no int. Moreover, the C standard doesn't impose restrictions on the width of an int other than that it must be able to hold

The ATtiny85 is an 8 bit MCU. It has no int. Moreover, the C standard doesn't impose restrictions on the width of an int other than that it must be able to hold values between -(2^15 - 1) and (2^15 - 1) (yes, you read that right, this is because before C2x int can be one's complement, two's complement or sign and magnitude). Now this is mainly C being an unforgiving language but realising this, it may be easier to piece together what's happening here. Since the ATtiny85 is an 8 bit MCU, anything wider than 8 bits has to be implemented in software. To keep the performance cost of heavy use of int as low as possible, the narrowest possible definition was used. This is in contrast to the author's system which probably uses 32 bit ints. I imagine the code when #included worked fine because of 32 bit ints and broke when compiled for the ATtiny85 because it used 16 bit ints. Warnings _could_ help here (and I believe the author when he says that the Arduino IDE had no obvious way of enabling them), but realistically the solution would have to re-write the code to use fixed width types. That way you could at least rely on the widths being the same. Although at least until C2x, you can't assume two's complement. That being said, it seems to me that trying to "simulate" the chip like this is always going to result in issues, especially when you try to emulate hardware. Probably the best solution here is to bite the bullet and learn how to use simavr which would pay off regardless of using C or Rust.