View Issue Details

IDProjectCategoryView StatusLast Update
0037547FPCCompilerpublic2020-08-23 23:41
ReporterKai Burghardt Assigned ToJonas Maebe  
PrioritynormalSeverityminorReproducibilityalways
Status resolvedResolutionduplicate 
Platformx86_64OSGNU/Linux 
Product Version3.0.4 
Summary0037547: high() and low() accept expressions
Descriptionhigh() and low() accept expressions, but should only accept ordinal and set data types, or array and set variables
Steps To Reproduceprogram dependentRangeDefinition(input, output, stdErr);
type
    foo = 0..7;
    // Note, this was an accidental programming error of mine:
    bar = 0..high(foo * 6);
begin
    writeLn(high(bar));
end.
Additional InformationThe maximum value an expression may assume is usually of minor interest, since we already know it is the processor’s native type.
TagsNo tags attached.
Fixed in Revision
FPCOldBugId
FPCTarget-
Attached Files

Relationships

duplicate of 0032994 new The Low and High functions allow an incorrect expression without errors 

Activities

Kai Burghardt

2020-08-11 16:19

reporter   ~0124769

Oh, gosh, I don’t know what “<type> <times> <constant>” is, but it isn’t an expression.

Florian

2020-08-14 19:48

administrator   ~0124884

Expressions must be accepted as it could be e.g. a function returning a dyn. array. Nevertheless, your example shouldn't compile.

CudaText man

2020-08-15 20:34

reporter   ~0124906

It is a pure syntax error. we cannot mulitply "type" to 6.

runewalsh

2020-08-15 21:06

reporter   ~0124907

Last edited: 2020-08-15 21:14

View 3 revisions

No, they should accept values. High(value) is often much more expressive than High(type):
var
  x: Vec4; // you can replace type without altering the rest!
begin
  for i := 0 to High(x.linearData) do
    ...
end;

vs

var
  x: Vec4;
begin
  for i := 0 to High(Vec4.linearData) do // must replace in 2 places now, not replacing will SILENTLY result in a logic error or a buffer overflow!
    ...
end;

Even «type * 6» looks fine for me; why not? Sometimes it's useful to know the type that expression yields; C++ has declval() specially for that, FPC has nothing.

Kai Burghardt

2020-08-15 21:58

reporter   ~0124910

OK, Florian, “expressions” isn’t the problem here. As Alextp pointed out, this is a syntax problem.

I disagree with runewalsh though: How is, for instance, high(42) in any way informative? On my x86_64 platform it will always yield 2^{63}−1. I _already_ know that.

Sven Barth

2020-08-16 14:15

manager   ~0124919

No, it's not a syntax problem. After all, in theory "type * value" could be a valid expression if I have e.g. an operator overload for a class reference (class of XXX and an LongInt). The problem here is that the typechecking does not correctly reject this expression with an error, because foo * 6 is definitely not valid.

Issue History

Date Modified Username Field Change
2020-08-11 16:17 Kai Burghardt New Issue
2020-08-11 16:19 Kai Burghardt Note Added: 0124769
2020-08-14 19:48 Florian Note Added: 0124884
2020-08-15 20:34 CudaText man Note Added: 0124906
2020-08-15 21:06 runewalsh Note Added: 0124907
2020-08-15 21:12 runewalsh Note Edited: 0124907 View Revisions
2020-08-15 21:14 runewalsh Note Edited: 0124907 View Revisions
2020-08-15 21:58 Kai Burghardt Note Added: 0124910
2020-08-16 14:15 Sven Barth Note Added: 0124919
2020-08-23 23:41 Jonas Maebe Assigned To => Jonas Maebe
2020-08-23 23:41 Jonas Maebe Status new => resolved
2020-08-23 23:41 Jonas Maebe Resolution open => duplicate
2020-08-23 23:41 Jonas Maebe FPCTarget => -
2020-08-23 23:41 Jonas Maebe Relationship added duplicate of 0032994