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

[Ondrej Pokorny]

On 15.07.2017 21:39, Jonas Maebe wrote:
> On 15/07/17 21:33, lazarus at kluug.net wrote:
>> Am Sa., Jul. 15, 2017 21:07 schrieb Jonas Maebe <jonas at freepascal.org>:
>>
>>     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.
>>
>> In this case you must not restrict us to work with invalid values in 
>> a deterministic way.
>
> You can if you always use explicit typecasts to different types and 
> access everything through pointers and assembly. But then the question 
> is why you want to use a restrictive type in the first place.
>
> Either you declare a type as only holding a limited set of data when 
> valid and assume it behaves as such, or you don't. A mixture is the 
> worst of both worlds: no type safety and unexpected behaviour when 
> something else assumes the type declaration actually means what is 
> written.

The problem is that you yourself force us to the mixture that "is the 
worst of both worlds".

On the one hand you say that the compiler can generate invalid values 
and on the other hand you say that the compiler can assume the enum 
holds only valid values. For now, there is absolutely no range checking 
and type safety for enums - so you can't use it as an argument.

You say "you declare a type as only holding a limited set of data when 
valid and assume it behaves as such" - yes I declare it as such but the 
compiler itself stores invalid data there. The compiler cannot assume 
the data holds only valid values if it happily stores invalid values itself!

Don't you understand the difference between compiler-point-of-view and 
the programmer-point-of-view?

Compiler layer:
- stores invalid enumeration values -> it cannot assume there are no 
invalid values

Programmer layer (two options - his decision):
1.) he checks all values in the enums himself and does range checking 
manually -> he and only he (not the compiler) can assume there are no 
invalid values.
2.) he doesn't do manual range checking -> he cannot assume there are no 
invalid values.

Again, you have two options:

1.) Give us full type safe enums with full range checking that CANNOT 
hold invalid values after any kind of operation (pointer, typecast, 
assembler ...). Then I am fully with you: keep the case optimization as 
it is (and introduce more optimizations).

2.) Keep the enums as they are (not type safe) and don't do any 
optimizations on type safety assumptions on the compiler level. Because 
there is no type safety.

 From my knowledge, the (1) option is utopia in a low-level languages 
along with Pascal.

For reference GNU-C: 
https://www.gnu.org/software/gnu-c-manual/gnu-c-manual.pdf page 11:
*"An enumeration is a custom data type used for storing constant integer 
values and referring to them by names."**
*
Pascal stores the enumeration values the same as C. It doesn't make 
sense to handle enums like you want them (which would make sense in 
high-level programming languages that Pascal is not).

Ondrej
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freepascal.org/pipermail/fpc-devel/attachments/20170716/0d6ed721/attachment.html>