Make floating point to character type conversions yield values within the type's range.

This affects cases where the floating value, truncated to an integer, is outside the range of the destination type. Previously, the result value might appear to be an int value outside the range of the character type.

These situations are undefined behavior under the C standards, so this was not technically a bug, but the new behavior is less surprising. (Note that it still may not raise the "invalid" floating-point exception in some cases where Annex F would call for that.)
This commit is contained in:
Stephen Heumann 2021-01-31 12:00:31 -06:00
parent 130d332284
commit 393fb8d635

16
Gen.pas
View File

@ -1317,10 +1317,20 @@ else if op^.q in [longToReal,uLongToReal] then begin
else
GenCall(13);
end {else}
else if op^.q in [realToByte,realToUbyte,realToWord] then begin
else if op^.q =realToWord then
GenCall(14)
else if op^.q = realToUbyte then begin
GenCall(14);
if (op^.q & $00FF) in [0,1] then
GenNative(m_and_imm, immediate, $00FF, nil, 0);
GenNative(m_and_imm, immediate, $00FF, nil, 0);
end {else if}
else if op^.q = realToByte then begin
lab1 := GenLabel;
GenCall(14);
GenNative(m_and_imm, immediate, $00FF, nil, 0);
GenNative(m_bit_imm, immediate, $0080, nil, 0);
GenNative(m_beq, relative, lab1, nil, 0);
GenNative(m_ora_imm, immediate, $FF00, nil, 0);
GenLab(lab1);
end {else if}
else if op^.q = realToUword then
GenCall(15)