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

[Jonas Maebe]

On 15/07/17 21:34, Martok wrote:
>> 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.
>>
>> I would assume that this is something that "someone with a solid
>> knowledge of the language" would expect.
> Probably. Subranges are after all explicit subsets of something. But let's not
> digress, right? That's not related to the topic at hand.

I mentioned it because we use exactly the same reasoning for subrange 
types as the one you consider completely unacceptable for enumeration 
types. Subrange types also consider only part of bit patterns that can 
be represented in their allotted memory space as valid, and any other 
value stored in there results in undefined behaviour. The case-statement 
optimisation happens for those types in exactly the same way, even 
though you can also force invalid values into them.

And you also have subranges of enum types. Can any assumptions made 
about those in your opinion?

But I finally understand where the disconnect comes from. I have always 
thought of enums as more or less equivalents of subrange types, simply 
with an optional name for the values. You, and indeed the Pascal 
standards, treat them differently.

Does that mean that you would consider the same transformation of a 
case-statement when using a subrange type as correct? And that putting a 
value outside the range of a subrange into such a variable as a 
programmer error? (as opposed to doing the same with a non-subrange enum 
type?)

> In any case, we have mode ISO for being extra-ISO-compatible - there are some
> significant differences between Borland Pascal and ISO/IEC already.

That is true. But I consider this behaviour a fundamental part of a 
type-safe language like Pascal. You want to make the language less 
strictly typed in order to have defined behaviour when using code that 
puts invalid values into variables.

> Note that FPC doesn't accept this code in mode (Obj)FPC, but correctly does so
> in DELPHI, with the same result as Delphi.

Maybe we can indeed change it in TP/Delphi modes, although I still think 
it is defeats the purpose of using enums in the first place.

And it would also require us to conditionalise every future optimisation 
based on type, in particular separating the treatment of enums from that 
of integers. That's a lot of (future) work and care to deal with what I 
still consider to be bad programming.


Jonas