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 typecasts and assembly.
> 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 array.
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 follo
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 yet
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 ini
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 th
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 som
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 ev
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 doc
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.
Severa
10 matches
Mail list logo
