Previously, the following rules were used for binary operators:
* If one of the values is a long, the result is long.
* If one of the values is unsigned, the result is also unsigned.
* Otherwise the result is an int.
C89 specifies the "usual arithmetic conversions" as:
* The integral promotions are performed on both operands.
* Then the following rules are applied:
* If either operand has type unsigned long int, the other operand is
converted to unsigned long int.
* Otherwise, if one operand has type long int and the other has type
unsigned int, if a long int can represent all values of an unsigned int,
the operand of type unsigned int is converted to long int; if a long int
cannot represent all the values of an unsigned int, both operands are
converted to unsigned long int.
* Otherwise, if either operand has type long int, the other operand is
converted to long int.
* Otherwise, if either operand has type unsigned int, the other operand is
converted to unsigned int.
* Otherwise, both operands have type int.
https://port70.net/~nsz/c/c89/c89-draft.html#3.2.1.5
As one example, these rules give a different result for an operator
with one long operand and one unsigned int operand. Previously,
the result type was unsigned long. With C89 semantics, it is just long,
since long can represent all unsigned ints.
Integral promotions convert types shorter than int to int (or unsigned int).
Both char and unsigned char are promoted to int since int can represent
all unsigned chars.
https://port70.net/~nsz/c/c89/c89-draft.html#3.2.1.1
Rename promoteint to ArithmeticConvert, since this is more accurate.
Fixes#170
Renamed GetReplacementType() to GetStructReplacementType().
Clarified in comments that most *Struct* facilities work for unions as well.
Made it clear in some error messages with regards to structs/unions.
That lets them match old-style definitions. It avoids "Type conflict" error messages. It allows shorter function calls.
Fixed the types of some variables in "test/ref/otccex.c". It avoids crashes on 64-bit Windows (32-bit Windows with 64-bit pointers).
The change allows cc65 to be compiled on 64-bit Windows, without getting warnings. That OS is actually 32 bits with 64-bit pointers. Its pointers are "long long" instead of "long". The change uses type-names that are configured for the actual pointer width.
The type needs to change (to array); but, the address shouldn't be changed -- it already points to the first element.
Based on a bug analysis by Daniel Serpell.
The code
void foo(void)
{
int i;
long l = 1L * i;
}
triggered an
Internal compiler error:
Code generation messed up: StackPtr is -4, should be -2
Greg King: "We are lucky that the bug is simple -- a missing "else". The result is that the compiler thinks that it does the opposite of what it actually does: It thinks that it pushes the non-constant expression onto the stack. It doesn't; so, cc65's stack pointer is wrong."