type
ta = array[boolean32] of byte;
var
a: ta;
b: boolean16;
begin
writeln(sizeof(ta));
word(b):=high(longint);
a[b]:=5; // writing to random memory
end.
Range checking can even not catch this, because explicit type casts disable them (so it cannot be caught during the assignment to b), and indexing operations only perform range checking when needed (when the value/variable you use for indexing has a different type than the range type, while they are the same here).type
tbparray = bitpacked array[0..7] of boolean8;
begin
writeln(sizeof(tbparray));
end.
This prints 1, because the compiler knows that the only valid values for boolean8 are 0 and 1, and hence it allocates only one bit to store their value. If any value between 0 and 255 were valid, then the size of that array would have to be 8 bytes (and the same for fields in bitpacked records).Range checking can even not catch this, because explicit type casts disable themThat is one of the contradictions that causes problems in FPC. Through casting the compiler allows values out of range to be assigned to a data type, consequently it cannot give itself the luxury of later assuming the value is in the declared range of the type, yet it does and, generates code based on that mistaken assumption.
<snip>
forcing variables to contain values that are out of range can never be supported, and may in the future always lead to different behaviour (or possibly only different behaviour on different platforms, or if different optimization settings are enabled). The reason is that the compiler uses the type information to optimize the code it generates. If this type information does not corresponds to the actual values that variables can contain, all bets are off.
Interesting code. On my machine in R+ mode it doesn't even compile. In R- mode, it is compiled, but the variable b is explicitly converted to 1, i.e. the compiler even provide such case:Code: [Select]type
ta = array[boolean32] of byte;
var
a: ta;
b: boolean16;
begin
writeln(sizeof(ta));
word(b):=high(longint);
a[b]:=5; // writing to random memory
end.
That is what explicit typecasting means: ignore all language and compiler checks, just do this. It's more or less the signature of the Borland-style Pascal family: strict type checking on the one hand (most of it at compile time, but some kinds can only be done at run time such as certain range and overflow checks), but at the same time the programmer has very low-level access and can explicitly circumvent/disable the type checking (usually, but not always, for performance reasons). In this second case, it's indeed the responsibility of the programmer that they don't break the type system, or anything else for that matter.Range checking can even not catch this, because explicit type casts disable themThat is one of the contradictions that causes problems in FPC. Through casting the compiler allows values out of range to be assigned to a data type,
<snip>
forcing variables to contain values that are out of range can never be supported, and may in the future always lead to different behaviour (or possibly only different behaviour on different platforms, or if different optimization settings are enabled). The reason is that the compiler uses the type information to optimize the code it generates. If this type information does not corresponds to the actual values that variables can contain, all bets are off.
Interesting code. On my machine in R+ mode it doesn't even compile. In R- mode, it is compiled, but the variable b is explicitly converted to 1, i.e. the compiler even provide such case:Code: [Select]type
ta = array[boolean32] of byte;
var
a: ta;
b: boolean16;
begin
writeln(sizeof(ta));
word(b):=high(longint);
a[b]:=5; // writing to random memory
end.
That is what explicit typecasting means: ignore all language and compiler checks, just do this.And the compiler should respect that but, it doesn't. Instead, for some constructs it decides to do something else which is not what the programmer told it to do. That's a problem.
It does: whenever you perform an explicit typecast, the compiler will at most warn that what you are doing is wrong (unless it has no idea how to perform the explicit typecast at all, like trying to typecast records of different sizes). It won't forbid you to do it. That's all what checks can do: warn, or forbid something.That is what explicit typecasting means: ignore all language and compiler checks, just do this.And the compiler should respect that but, it doesn't.
Instead, for some constructs it decides to do something else which is not what the programmer told it to do. That's a problem.I really don't know anymore how else I can explain to you that there is nothing arbitrary about the array example you are so hung up on. Maybe this:
There is a difference between a compiler doing range checking and a compiler downright imposing some range it arbitrarily chose, particularly when the programmer didn't even ask for range checking.
type
arrayrange = 0..0;
tarray1 = array[arrayrange] of byte;
tarray2 = array[0..0] of byte;
The above declarations are equivalent. Declaring an array type always implies declaring two types: a range/index type, and the array type itself.It does: whenever you perform an explicit typecast, the compiler will at most warn that what you are doing is wrong (unless it has no idea how to perform the explicit typecast at all, like trying to typecast records of different sizes). It won't forbid you to do it. That's all what checks can do: warn, or forbid something.It would be _great_ if it gave at least a warning or downright forbid it instead of silently producing incorrect code.
I really don't know anymore how else I can explain to you that there is nothing arbitrary about the array example you are so hung up on.At least we've managed to have a meeting of the minds on that one.
Maybe this:So far, so good but, as you, yourself pointed out below, one of those types is an implied type, not a declared type and, I'm sure you know I am referring to the implied type of the array range.Code: [Select]typeThe above declarations are equivalent. Declaring an array type always implies declaring two types: a range/index type, and the array type itself.
arrayrange = 0..0;
tarray1 = array[arrayrange] of byte;
tarray2 = array[0..0] of byte;
When you index an array, the index will always be converted to the range type. This is not an explicit type conversion, but an implicit type conversion.
The compiler will not perform any range checking for this conversion, unless range checking is enabled.It did worse than that, it forced a signed data type to become an unsigned type based on the completely incorrect assumption that the constant zero indicates a Pascal unsigned type, which it does not.
This conversion does the following things:That's all fine and dandy but, the conversion and the result is driven by the declared types of the _variables_ and in the cases where the constant drives the conversion, it _promotes_ the variables to a superset type e.g int32 to int64. A constant can never demote a variable's declared type which is what FPC did in the specific case we are talking about.
* it checks for type compatibility between the index you passed and the declared type. This is what causes a compile-time type conversion error if you try to index an array with e.g. an ansistring. If no implicit type conversion would be inserted, such errors would not be caught.
* it performs a range check if range checking is enabled
In the above example, it is hence assumed to contain a value in the range 0..0. So the compiler will generate code that is valid as long as the index contains a value within this range. At this point, the compiler has no clue any more about what the original type of the index variable was.The compiler cannot assume that a variable does or does not contain the value that the range denotes. It can check that the variable is in the range if and only if the programmer has told it to do so. Otherwise, the compiler's job is to calculate the address referenced using the old "address(array_variable) + (n * elementsize)" where n is the programmer specified index not some value the compiler decided to use because it mistakenly believes that the constant zero is only a member of the unsigned Pascal datatypes (we both know that zero belongs to both, signed and unsigned types. That alone tears down every argument you've presented to justify that FPC bug.)
Again, this is unrelated to range checking or explicit type casts. And it is not arbitrary, because it the compiler is using literally the range type that the programmer told the compiler to use for this array.I'm guessing that applies to the Boolean thing this thread is actually about. I have no comment on that.
This would mean giving a warning for or forbidding any implicit casting between integer types. Every single real-world program would throw hundreds if not thousands of such warnings. As mentioned in the other thread, Ada follows this approach and gives an error whenever one integer type need to be converted to another if the target type cannot represent the entire range of the source type (and you need to use an explicit cast instead). It is a valid approach, but not how Pascal is defined by any official or de facto standard. In Pascal such checks are optional, at run time, through range checking.It does: whenever you perform an explicit typecast, the compiler will at most warn that what you are doing is wrong (unless it has no idea how to perform the explicit typecast at all, like trying to typecast records of different sizes). It won't forbid you to do it. That's all what checks can do: warn, or forbid something.It would be _great_ if it gave at least a warning or downright forbid it instead of silently producing incorrect code.
The conversion is implicit, but not the type itself or its declaration. Look at the formal definition of an array: https://www.freepascal.org/docs-html/current/ref/refsu14.html . The range type is simply an ordinal type. It is part of the declaration of the array type. The type conversions to the range type are implicit, but the same goes for any time you pass a parameter, assign a value to another variable/fields etc (all of which also have declared types). And in all of those cases, if you pass an out-of-range type, the result is undefined.Maybe this:So far, so good but, as you, yourself pointed out below, one of those types is an implied type, not a declared typeCode: [Select]typeThe above declarations are equivalent. Declaring an array type always implies declaring two types: a range/index type, and the array type itself.
arrayrange = 0..0;
tarray1 = array[arrayrange] of byte;
tarray2 = array[0..0] of byte;
You use an expression of Type A in a context that expects Type B. Hence, the expression gets converted to Type B. That is all there is to it, and how it works everywhere in the language, from indexing arrays to passing parameters and assigning values. No assumption gets made, and there are no implicit/explicit type declarations or assumptions.When you index an array, the index will always be converted to the range type. This is not an explicit type conversion, but an implicit type conversion.
This is where things start going awfully wrong. The index has a declared type and the compiler, in the specific example we are both thinking about, chose to override an explicit type declaration with an incorrect data type assumption it made.
It's not the constant zero. It's the subrange type 0..0. These are completely different things. And the compiler assumes that an expression of this type can have no other valid value that 0, which is correct according to the declaration.The compiler will not perform any range checking for this conversion, unless range checking is enabled.It did worse than that, it forced a signed data type to become an unsigned type based on the completely incorrect assumption that the constant zero indicates a Pascal unsigned type, which it does not.
On the contrary, it must assume that. It is the whole and only point of type information.In the above example, it is hence assumed to contain a value in the range 0..0. So the compiler will generate code that is valid as long as the index contains a value within this range. At this point, the compiler has no clue any more about what the original type of the index variable was.The compiler cannot assume that a variable does or does not contain the value that the range denotes.
On the contrary, it must assume that. It is the whole and only point of type information.I was hoping that since you had had a few days to think about it, you might have at least some doubts (and you should!!)
The Pascal standard (http://pascal-central.com/iso7185.html#6.4.3.2%20Array-types) says I shouldn't, especially regarding arrays:On the contrary, it must assume that. It is the whole and only point of type information.I was hoping that since you had had a few days to think about it, you might have at least some doubts (and you should!!)
Let i denote a value of the index-type ; let Vi denote a value of that component of the array-type that corresponds to the value i by the structure of the array-type ; let the smallest and largest values specified by the index-type be denoted by m and n, respectively ; and let k = (ord(n)-ord(m)+1) denote the number of values specified by the index-type ; then the values of the array-type shall be the distinct k-tuples of the formWhile TP/Delphi/FPC-style Pascal is not the same as ISO Standard Pascal, the definition of how regular arrays behave is still the same.
(Vm ,...,Vn ).
NOTE -- 2 A value of an array-type does not therefore exist unless all of its component-values are defined. If the component-type has c values, then it follows that the cardinality of the set of values of the array-type is c raised to the power k.
The Pascal standard (http://pascal-central.com/iso7185.html#6.4.3.2%20Array-types) says I shouldn't, especially regarding arrays:Rather basic and plain vanilla stuff that doesn't support or justify your argument. However, what is not stated is interesting. Among them, the compiler being free to _demote_ variable types.... assuming that the range is of a particular type or "assigning" it one. Also conspicuously missing is that it does not say that zero is a member of positive types only. IOW, there are quite a few things in your flawed argument that the standard (unsurprisingly) does not "address".QuoteLet i denote a value of the index-type ; let Vi denote a value of that component of the array-type that corresponds to the value i by the structure of the array-type ; let the smallest and largest values specified by the index-type be denoted by m and n, respectively ; and let k = (ord(n)-ord(m)+1) denote the number of values specified by the index-type ; then the values of the array-type shall be the distinct k-tuples of the form
(Vm ,...,Vn ).
NOTE -- 2 A value of an array-type does not therefore exist unless all of its component-values are defined. If the component-type has c values, then it follows that the cardinality of the set of values of the array-type is c raised to the power k.
It says that only the array elements defined by its index-type exist. So in an array[0..0], only element 0 exist. Addressing a non-existent element in an array is an error.The Pascal standard (http://pascal-central.com/iso7185.html#6.4.3.2%20Array-types) says I shouldn't, especially regarding arrays:Rather basic and plain vanilla stuff that doesn't support or justify your argument.QuoteLet i denote a value of the index-type ; let Vi denote a value of that component of the array-type that corresponds to the value i by the structure of the array-type ; let the smallest and largest values specified by the index-type be denoted by m and n, respectively ; and let k = (ord(n)-ord(m)+1) denote the number of values specified by the index-type ; then the values of the array-type shall be the distinct k-tuples of the form
(Vm ,...,Vn ).
NOTE -- 2 A value of an array-type does not therefore exist unless all of its component-values are defined. If the component-type has c values, then it follows that the cardinality of the set of values of the array-type is c raised to the power k.
It says that only the array elements defined by its index-type exist. So in an array[0..0], only element 0 exist. Addressing a non-existent element in an array is an error.In that case, there are more bugs in FPC as the code snippet below demonstrates
You are correct that FPC does not generate compile-time errors in all cases when it detects undefined behaviour. I explained why in the other thread: compatibility with older Delphi-versions. This will probably be changed into an error at some point, at the very least for the delphiunicode mode (which corresponds to Delphi 2009+) and for the FPC/ObjFPC modes.It says that only the array elements defined by its index-type exist. So in an array[0..0], only element 0 exist. Addressing a non-existent element in an array is an error.In that case, there are more bugs in FPC as the code snippet below demonstrates.
You can't have it both ways. If indexing out of range is an error then FPC should not compile the statements in the code snippet above. If it compiles them then it should produce code that is semantically correct, in this case, address(array) + (n * elementsize).As explained by the Pascal standard quoted above, that is not the semantics of the array indexing operation in Pascal. It's the semantics of array indexing in C/C++.
when it decided to unceremoniously mutilate a signed variable into an unsigned one, it did so silently, no warningWhy do you keep repeating this? I must have answered with the explanation about how type checking and type conversions work, the fact that your programs would get hundreds of warnings if we did warn in such scenarios, the comparison with Ada, and the concept of range checking, about five times by now. The program will not be silently go wrong if you enable range checking. That is the whole and sole purpose of range checking: emit errors at run time for cases that cannot be checked at compile time.
Since you justify _forcing_ variables to be in the declared range of an array, how do you justify that FPC did _not_ turn the indexing numerals 5 and -5 into zero ? or is mutilation a "feature" reserved for variables only ?Indexing an array out of its bounds is an error. The result of erroneous code is undefined. Turning such indices into zero would be therefore be "correct". Not turning them into zero is equally correct (that's why Delphi's behaviour is also correct). It's the difference between undefined (anything can happen at any time) and implementation-defined (the compiler can choose what happens, but it needs to be consistent). Undefined behaviour is unpredictable by its very nature.
You are correct that FPC does not generate compile-time errors in all cases when it detects undefined behaviour. I explained why in the other thread: compatibility with older Delphi-versions. This will probably be changed into an error at some point, at the very least for the delphiunicode mode (which corresponds to Delphi 2009+) and for the FPC/ObjFPC modes.You can't quote standards then wrap them in a sheet of Delphi compatibility to justify bugs. Obviously no standard can be used to redefine proven mathematical theory and justify the totally erroneous decision that zero (0) is a positive-only number.
As explained by the Pascal standard quoted above, that is not the semantics of the array indexing operation in Pascal. It's the semantics of array indexing in C/C++.The standards passage you quoted does not say anything about how arrays and their elements are arranged in memory and how the address of said elements are determined. Its main point is the determination of the number of elements in the array and their applicable range. I will note too, that it doesn't say anything at all about the type of the range, which you have been using to justify that bug in FPC (or more accurately and worse, claim it is not a bug.)
Why do you keep repeating this? I must have answered with the explanation about how type checking and type conversions work, the fact that your programs would get hundreds of warnings if we did warn in such scenarios, the comparison with Ada, and the concept of range checking, about five times by now. The program will not be silently go wrong if you enable range checking.I keep repeating it because you are grossly misusing range and type checking to justify FPC's incorrect code generation. An array whose range consists of constants cannot always be assigned a type unambiguously and, when the range is 0..0 then no type can be assigned to it. Assigning a type to it, is mathematically incorrect, forcing that incorrect type onto a variable that _does_ have a declared type is beyond incorrect, it's dismal.
That is the whole and sole purpose of range checking: emit errors at run time for cases that cannot be checked at compile time.The compiler didn't do any range checking (it wasn't asked to do any either.) but, it turned a 32bit signed integer into a 64bit unsigned integer. No definition of range checking covers that kind of behavior.
Indexing an array out of its bounds is an error.That almost sounds reasonable but, then the existence of open arrays is an error in itself. Those array don't even have a declared range much less a type associated with it. To make matters even worse, their number of elements can vary at runtime. That definitely violates the standards passage you quoted.
The result of erroneous code is undefined. Turning such indices into zero would be therefore be "correct". Not turning them into zero is equally correct (that's why Delphi's behaviour is also correct). It's the difference between undefined (anything can happen at any time) and implementation-defined (the compiler can choose what happens, but it needs to be consistent). Undefined behaviour is unpredictable by its very nature.You cannot, as you are attempting to, claim that AnArray[SomeIndex] is erroneous code. If it were "erroneous" as you pretend it is then, indexing open arrays is erroneous (by the definition you are attempting to slide, not mine.) With a "normal" array, it simply may or may not be correct. The compiler's job is to compute the address referenced _correctly_, emphasis on _correctly_ which FPC fails to do. And it fails to do that, not because it didn't generate the correct code to calculate the address but, because it mutilated the indexing variable.
It's inherent to trying to be compatible to undefined behaviour of another compiler (which we tried in the past, hence the allowed out-of-range constants), and why it's such a bad idea (people will expect that you'll stay compatible to it in all possible forms and future versions, which is perfectly understandable but equally untenable).You can't hide that bug behind the incorrect claim of "undefined behavior". If it were "undefined" as you pretend it is, why do most compilers not only get it right but, do it the same way.
It says that only the array elements defined by its index-type exist. So in an array[0..0], only element 0 exist. Addressing a non-existent element in an array is an error.In that case, there are more bugs in FPC as the code snippet below demonstrates .....
Based on your last statement compiling case 1 and case 2 are errors yet, FPC compiles them (and it should not), it does emit a warning, that's nice but that doesn't justify compiling those erroneous statements.
...
It seems FPC is rather choosy and unpredictable when it comes to complying with Pascal standards.
With range checking on, FPC does not compile that.That demonstrates that FPC is mixing apples and oranges. Range checking isn't meant to change the compile time data type of a variable. It's purpose is to tell the compiler to generate code to verify that a _variable_ is in the specified range at _run time_ not compile time (since it obviously cannot do it at compile time when a variable is used). Pascal's strong type checking is neither associated nor dependent in any way on any runtime feature, such as range checking.
Doesn't just simply fall into the category of undefined behavior? As in: cannot be relied upon in any specific way, because the output is not defined?The claim that there is something undefined is yet another instance of mixing apples and oranges. The result, when the variable is not in the range is undefined but, there is nothing undefined as far as code generation is concerned.