Re: [fpc-devel] Dangerous optimization in CASE..OF

2017-07-15 Thread Jonas Maebe
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

Re: [fpc-devel] Dangerous optimization in CASE..OF

2017-07-15 Thread Martok
> 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

Re: [fpc-devel] Dangerous optimization in CASE..OF

2017-07-15 Thread lazarus
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

Re: [fpc-devel] Dangerous optimization in CASE..OF

2017-07-15 Thread Florian Klämpfl
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

Re: [fpc-devel] Dangerous optimization in CASE..OF

2017-07-15 Thread Jonas Maebe
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

Re: [fpc-devel] Dangerous optimization in CASE..OF

2017-07-15 Thread lazarus
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

Re: [fpc-devel] Dangerous optimization in CASE..OF

2017-07-15 Thread Jonas Maebe
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

Re: [fpc-devel] Dangerous optimization in CASE..OF

2017-07-15 Thread Martok
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

Re: [fpc-devel] Dangerous optimization in CASE..OF

2017-07-15 Thread Jonas Maebe
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

Re: [fpc-devel] Dangerous optimization in CASE..OF

2017-07-15 Thread 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 even FPC follows only in this one single spot.