View Issue Details

IDProjectCategoryView StatusLast Update
0037342FPCCompilerpublic2020-10-04 13:56
ReporterBoris Matkov Assigned ToJonas Maebe  
PrioritynormalSeverityminorReproducibilityalways
Status resolvedResolutionno change required 
Product Version3.2.0 
Summary0037342: Regression: range check warning
DescriptionRegression: range check warning
Steps To Reproducetry to compile this code:

type
  TMySet = (meOne, meTwo, meThree);

function Get1: TMySet;
begin
  Result := TMySet(5);
end;

function Get2: TMySet;
var
  i: Integer;
begin
  i := 5;
  Result := TMySet(i);
end;

In FPC 3.0.4 this code will be compiled without warnings. In FPC 3.2.0 I get warning:
Warning: range check error while evaluating constants (5 must be between 0 and 2)
but only in the Get1 function. In the Get2 function compiler do not show warning. In this case this warning does not make sense and behavior in FPC 3.0.4 was correct, when compiler do not show warning in both cases (like in Delphi).
TagsNo tags attached.
Fixed in Revision
FPCOldBugId
FPCTarget-
Attached Files

Relationships

related to 0016006 closedJonas Maebe Dead code mistake 
has duplicate 0037847 feedbackJonas Maebe Integer constant declaration using typecasting generates range error at usage 

Activities

Tomas Hajny

2020-07-13 11:08

manager   ~0123960

Why should this be a regression, what's incorrect on the warning? The warning correctly points out that the assigned value is clearly outside of the defined range. The compiler cannot detect the second case, because it doesn't evaluate the value assigned to the passed variable, that's why the warning is issued only for the first case.

Please note that Delphi happily accepts many potentially dangerous constructs without any warning, FPC will never attempt to be compatible to Delphi as far as issued warnings are concerned. The code is as compilable with FPC as it is with Delphi. If you don't like your code to issue the warning, you can turn it off (even locally) using the {$WARN ...} directive (e.g. by putting {$PUSH} {$WARN 4110 OFF} and {$POP} around the Get1 definition).

J. Gareth Moreton

2020-07-13 11:54

developer   ~0123963

Tomas beat me to it. This warning looks legitimate to me because the number 5 is outside of the valid ordinal range of the enumeration. For the second example, constant propagation doesn't take place until after syntax parsing, so the compiler does not know that the variable definitely contains a value of 5 when it is typecast. In this situation, you are bypassing the normal range safeguards with the explicit typecast and hence the compiler trusts that you know what you're doing and ensuring you're not trying to assign something invalid.

With permission, I would like to close this as "not a bug".

Jonas Maebe

2020-07-14 21:30

manager   ~0124015

Last edited: 2020-10-04 13:56

View 3 revisions

The issue is that Delphi treats enumeration types as a mixture of C enums (an integer type that spans the entire range of the underlying storage size with some named values) and subrange types (a type where only the values part of the subrange are valid). The result is, however, inconsistent, see e.g. https://www.mail-archive.com/fpc-devel@lists.freepascal.org/msg38722.html

FPC on the other hand treats enumeration types and subrange types in the same way (and always has done so): any value outside the declared range is invalid (for enumerations with holes, the range spans the lowest declared value to the highest declared value), which means the program behaviour is undefined if you try to use such an invalid value stored in an enumeration/subrange variable (similar to how forcing a random pointer value into an ansistring makes the program behaviour undefined). This has various consequences, the most known of which are https://bugs.freepascal.org/view.php?id=16006 and https://bugs.freepascal.org/view.php?id=32079.

And while normally we would make such behaviour modeswitch dependent, that does not work here because values can very easily cross boundaries of units compiled in different modes. See https://forum.lazarus.freepascal.org/index.php/topic,45507.msg322059.html#msg322059 for a more extensive explanation.

This warning was added to make it clearer that such code is invalid in FPC.

Issue History

Date Modified Username Field Change
2020-07-13 10:29 Boris Matkov New Issue
2020-07-13 11:08 Tomas Hajny Note Added: 0123960
2020-07-13 11:54 J. Gareth Moreton Note Added: 0123963
2020-07-14 21:30 Jonas Maebe Assigned To => Jonas Maebe
2020-07-14 21:30 Jonas Maebe Status new => resolved
2020-07-14 21:30 Jonas Maebe Resolution open => no change required
2020-07-14 21:30 Jonas Maebe FPCTarget => -
2020-07-14 21:30 Jonas Maebe Note Added: 0124015
2020-07-14 21:30 Jonas Maebe Relationship added related to 0016006
2020-10-01 11:22 Jonas Maebe Relationship added duplicate of 0037847
2020-10-01 11:23 Jonas Maebe Note Edited: 0124015 View Revisions
2020-10-01 11:23 Jonas Maebe Relationship replaced has duplicate 0037847
2020-10-04 13:56 Jonas Maebe Note Edited: 0124015 View Revisions