the compiler is arbitrarily stopping upconversion at int even though I fee it shorts and want an int64_t on assignment. it is not taking the next steps in upconverting.
upconverting should be done like a while loop. like the list of conversions you had above. they are stopping short at *1* conversion. I am saying it shouldn't stop converting until it reaches the target data type (or hits a conversion error), which is:
- function argument
- left hand side of assignment op
- generally reaching the target of the expression evaluation
- returning something from a function
- there may be other examples, but they still boil down to the same thing
one possible implementation might be like this algorithm (for usage in parser sort of):
1 2 3 4 5 6 7 8 9 10 11 12
|
COMMENT: find highest data type in expression
highest_data_type=NULL
for every data_type in expression_tree do
if (NULL==highest_data_type) then
if (data_type==integer and data_type.width > highest_data_type.width) then
highest_data_type=data_type
endif
endif
done
COMMENT: after this,it's just a matter of walking the syntax tree again
COMMENT: and generating code that upconverts any data_type that is
COMMENT: data_type.width < highest_data_type.width
|
the for is actually a syntax tree walk, so it's recursive...
do you mean
function(int int*int*int)? it should leave them as an int. handling overflow should be the programmer's responsibility as usual.
function(long int*int*int) it should convert them to a long or produce some sort of data type error.
function(int64_t int*int*int) it should upconvert the ints to int64_ts as part of the eval.
what sense would it make to not fully upconvert expressions?
the compiler already piecemeal-does it now.
I don't know if the actual translation would be table driven or not in order to check for conversion type errors, that would be a simple matter to put in a compiler.
having such a compiler fix would sure would eliminate a lot of confusion.