View Issue Details

IDProjectCategoryView StatusLast Update
0037847FPCCompilerpublic2020-10-04 14:04
ReporterTotoliciu Denis Dan Assigned ToJonas Maebe  
PrioritynormalSeverityminorReproducibilityalways
Status feedbackResolutionopen 
Product Version3.2.0 
Summary0037847: Integer constant declaration using typecasting generates range error at usage
DescriptionTrying to use "CValueErr" constant anywhere in the program will generate the following error:

BugTest.lpr(13,11) Error: range check error while evaluating constants (0 must be between 10 and 20)

The compiler will not generate any error if:
* the line where "CValueErr" is used is commented and
* the declaration of the constant if left as it is, without deleting it or commenting it.

This way of declaring and using the constant "CValueErr" is compilable with Delphi.
Steps To Reproducetype
  TInterval = 10..20;

const
  CValueErr = TInterval(0);
  CValueGood: TInterval = TInterval(0);

begin
  WriteLn(CValueErr); // generate range checking error
  WriteLn(CValueGood); // OK
end.
TagsNo tags attached.
Fixed in Revision
FPCOldBugId
FPCTarget-
Attached Files

Relationships

duplicate of 0037342 resolvedJonas Maebe Regression: range check warning 

Activities

Totoliciu Denis Dan

2020-09-30 23:27

reporter  

BugTest.zip (50,282 bytes)

Thaddy de Koning

2020-10-01 09:30

reporter   ~0126014

That is not a bug.

Jonas Maebe

2020-10-01 11:23

manager   ~0126018

See https://bugs.freepascal.org/view.php?id=37342#c124015 for the details

Totoliciu Denis Dan

2020-10-04 13:50

reporter   ~0126078

What is confusing about the way the compiler treats the issue is this:
1) for `CValueErr` the compiler probably infers the type from its typecasted value `TInterval(0)` and can't be used anywhere else in the program because at that point the compiler will issue a range checking *error*, not a warning as in the case of the constant declaration; which in my opinion is correct to have a warning about the issue;
2) for `CValueGood` the compiler warns about a range checking problem, which is correct, but the big difference is that you can use `CValueGood` anywhere in the program!

So in my opinion, this is more about consistency of the program in the sense that if the compiler either infers a type of a constant, either has the type of the constant explicitly declared, then it should behave the same in terms of warnings and errors. That means that either both constants should not be usable anywhere in the program and have a range checking *error* triggered by the compiler at the place of usage, either the compiler should only issue a range checking *warning* in both cases, which in my opinion is more suited.

Totoliciu Denis Dan

2020-10-04 14:03

reporter   ~0126080

Last edited: 2020-10-04 14:04

View 2 revisions

The bug can be clearly seen in the following piece of source code:

type
  TInterval = 10..20;

const
  CValueErr = TInterval(0);
  CValueGood: TInterval = TInterval(0);

var
  x, y: TInterval;

begin
  x := CValueGood; // works OK
  y := CValueErr; // does not work, range checking error
// neither the followings work
  y := TInterval(CValueErr);
  y := TInterval(Integer(CValueErr));
end.

`y` can never be assigned because `CValueErr` will issue anywhere it is used in the program a range checking *error*, in any kind of expression.

Issue History

Date Modified Username Field Change
2020-09-30 23:27 Totoliciu Denis Dan New Issue
2020-09-30 23:27 Totoliciu Denis Dan File Added: BugTest.zip
2020-10-01 09:30 Thaddy de Koning Note Added: 0126014
2020-10-01 11:22 Jonas Maebe Relationship added has duplicate 0037342
2020-10-01 11:23 Jonas Maebe Assigned To => Jonas Maebe
2020-10-01 11:23 Jonas Maebe Status new => resolved
2020-10-01 11:23 Jonas Maebe Resolution open => duplicate
2020-10-01 11:23 Jonas Maebe FPCTarget => -
2020-10-01 11:23 Jonas Maebe Note Added: 0126018
2020-10-01 11:23 Jonas Maebe Relationship replaced duplicate of 0037342
2020-10-04 13:50 Totoliciu Denis Dan Note Added: 0126078
2020-10-04 14:03 Totoliciu Denis Dan Status resolved => feedback
2020-10-04 14:03 Totoliciu Denis Dan Resolution duplicate => open
2020-10-04 14:03 Totoliciu Denis Dan Note Added: 0126080
2020-10-04 14:04 Totoliciu Denis Dan Note Edited: 0126080 View Revisions