On 15/07/17 21:33, laza...@kluug.net wrote:
Am Sa., Jul. 15, 2017 21:07 schrieb Jonas Maebe :
I have said from the start that it is possible to store invalid values
in variables through the use of a.o. pointers (which is what the class
zeroing does), explicit
> This will never generate a range check error, because the type
> information states that a tsubenum2 value is always a valid tsubenum
> value. Array indexing a special case of this, as semantically the
> expression you use to index the array is first assigned to the range
> type of the
Am Sa., Jul. 15, 2017 21:07 schrieb Jonas Maebe :
On 15/07/17 20:52, laza...@kluug.net (mailto:laza...@kluug.net) wrote:
On one hand, you try to be very fundamental about enums - you say that
only declared enum values are valid. And there is no zero value for
TMyEnum. TMyEnum is declared as
Am 15.07.2017 um 17:17 schrieb Martok:
> Several different ways of writing the (apparent) tautology "is EnumVar in
> Low(EnumType)..High(EnumType)" all handle out-of-range-values (expressly, not
> as
> a side effect of something else).
... only because nobody implemented such an optimization
On 15/07/17 20:52, laza...@kluug.net wrote:
On one hand, you try to be very fundamental about enums - you say that
only declared enum values are valid. And there is no zero value for
TMyEnum. TMyEnum is declared as follows:
TMyEnum = (one = 1, two);
TMyEnum is not a number so it cannot be
Am Sa., Jul. 15, 2017 12:45 schrieb Jonas Maebe :
Classes are explicitly documented to initialise their contents with
zero
Excuse me, but you have a collision in the way you think :)
On one hand, you try to be very fundamental about enums - you say that only
declared enum values are valid. And
On 15/07/17 17:17, Martok wrote:
For example, if I index an array, I know bad things may happen if I don't check
the index beforehand, so I must always do that.
No, you don't always have to do that. That is the whole point of a type
system.
That if the compiler makes up the array access
Am 15.07.2017 um 12:40 schrieb Jonas Maebe:
> On 14/07/17 02:40, Martok wrote:
>> There is a fundamental difference in the type system between a somewhat
>> sensible (if unexpected) assumption in FPC and a more practical documented
>> definition in every other Pascal compiler. An assumption that
On 14/07/17 20:21, Ondrej Pokorny wrote:
In this case, please fix the compiler so that it doesn't generate
invalid values by default:
program Project1;
{$mode objfpc}{$H+}
type
TMyEnum = (one = 1, two);
TMyClass = class
public
Enum: TMyEnum;
end;
Classes are explicitly
On 14/07/17 02:40, Martok wrote:
There is a fundamental difference in the type system between a somewhat sensible
(if unexpected) assumption in FPC and a more practical documented definition in
every other Pascal compiler. An assumption that even FPC follows only in this
one single spot.
10 matches
Mail list logo