View Issue Details

IDProjectCategoryView StatusLast Update
0035915FPCCompilerpublic2019-08-03 15:50
ReporterThaddy de KoningAssigned ToJonas Maebe 
PrioritynormalSeverityminorReproducibilityalways
Status resolvedResolutionfixed 
Product Version3.3.1Product Build42543 
Target VersionFixed in Version3.3.1 
Summary0035915: In mode extendedpascal a run-time error is thrown on a case statement with a literal selector, should be compile-time error.
DescriptionIn mode extendedpascal a run-time error is thrown on a literal selector that has no label, but should throw a compile time error since the literal is resolved at compile time.
Steps To ReproduceThis should throw compile time error and not a run-time error:
{$mode extendedpascal}
program iso10206bug(infile,outfile);
type
  operator = 3..5;
var
  x:integer;
  o:operator = 4;
begin
  x:=1;
  case o of
    3 : x := x;
    5 : x := x;
  end;
end.

Whereas this should throws a correct run-time error:

{$mode extendedpascal}
program iso10206bug2(infile,outfile);
type
  operator = 3..5;
  
procedure testme(const o:operator);
var
  x:integer;
begin
  x:=1;
  case o of
    3 : x := x;
    5 : x := x;
  end;
end;

begin
  Testme(4);
end.

The latter is correct: error 201
Additional InformationDiscovered during researching case bug in iso mode, but this is in $extendedpascal mode
TagsNo tags attached.
Fixed in Revision42574
FPCOldBugId
FPCTarget-
Attached Files

Activities

Thaddy de Koning

2019-07-31 09:00

reporter   ~0117515

strictly speaking it is not a literal, but it should still be compile time.

J. Gareth Moreton

2019-07-31 10:06

developer   ~0117517

In this case o is just a variable with an initialised value. Is it entirely reasonable to expect the compiler to keep track of the exact value compared to just knowing if it's initialised or not? Such a system requires extensive data flow analysis. Yes, okay it's fairly straightforward in this instance, but there could easily be some mathematics performed on o before the case block is reached. This set-up seems very contrived.

Thaddy de Koning

2019-07-31 11:15

reporter   ~0117519

Last edited: 2019-07-31 11:24

View 3 revisions

It may be contrived (I don't think it is) . But it satisfies Popper's falsification, something I hold dearly. It should be used more often in computer science.
Popper's theory can be explained as:
If there is one! valid counter example all verifications are invalid.

J. Gareth Moreton

2019-07-31 13:45

developer   ~0117523

It is a good paradigm to go by, but one must consider what is a reasonable demand on the compiler. If data-flow analysis is enabled (which might become more sophisticated when I implement pure functions), then if the compiler can detect such a situation, then sure, raise an error, but to demand such a thing all the time may incur far too large a performance penalty on the compiler.

Jonas Maebe

2019-08-03 15:50

manager   ~0117556

The standards only say the compiler has to give an error if it can statically determine an unhandled case statement will be picked. The compiler does that now.

The standards do not specify under which conditions the compiler has to be able to statically determine this. It will also always depend on optimisation settings.

Issue History

Date Modified Username Field Change
2019-07-31 08:59 Thaddy de Koning New Issue
2019-07-31 09:00 Thaddy de Koning Note Added: 0117515
2019-07-31 10:06 J. Gareth Moreton Note Added: 0117517
2019-07-31 11:15 Thaddy de Koning Note Added: 0117519
2019-07-31 11:22 Thaddy de Koning Note Edited: 0117519 View Revisions
2019-07-31 11:24 Thaddy de Koning Note Edited: 0117519 View Revisions
2019-07-31 13:45 J. Gareth Moreton Note Added: 0117523
2019-08-03 15:50 Jonas Maebe Assigned To => Jonas Maebe
2019-08-03 15:50 Jonas Maebe Status new => resolved
2019-08-03 15:50 Jonas Maebe Resolution open => fixed
2019-08-03 15:50 Jonas Maebe Fixed in Version => 3.3.1
2019-08-03 15:50 Jonas Maebe Fixed in Revision => 42574
2019-08-03 15:50 Jonas Maebe FPCTarget => -
2019-08-03 15:50 Jonas Maebe Note Added: 0117556