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

[DaWorm]

If the programmer builds a case statement on an enum, that includes all of
the possible enum values, and also includes an else clause, to me it seems
the programmer is implicitly telling the compiler that there is the
possibility of illegal values stored in the enum.

Does the compiler optimize away the else clause in this case?  Seems to me
it should not.  At least that isn't the behavior I would expect as a user.

Jeff

On Jul 16, 2017 7:40 AM, "Jonas Maebe" <jonas at freepascal.org> wrote:

> On 16/07/17 09:12, Ondrej Pokorny wrote:
>
>> 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.
>>
>
> It can assume this because a program's behaviour is only defined if you
> initialise your variables first with valid values. This is not just the
> case for enums, for any type. If you don't initialise a local longint
> variable, the compiler could transform your program as if it was
> initialised with -12443, for example. The reason is that the behaviour of
> your program is undefined in that case, so any behaviour the compiler could
> come up with would be "correct".
>
> The same goes if you use an enum variable that does not contain a valid
> value.
>
> For now, there is absolutely no range checking and type safety for enums -
>> so you can't use it as an argument.
>>
>
> There is just as much range checking and type safety for enums as there is
> for any other type.
>
>  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
>>
> With your argument, there is no type safety for ansistrings either. After
> all, it's very easy to get an ansistring with an invalid initial value with
> something like this:
>
> type
>   trec = record
>     a: ansistring;
>   end;
>   prec = ^trec;
> var
>   p: prec;
> begin
>   getmem(p,sizeof(trec));
>   p^.a:='abc'; // undefined behaviour
> end.
>
> Nevertheless, the compiler never adds code to check whether an ansistring
> actually points to valid ansistring data before it uses it. It simply
> assumes that you, as a programmer, made sure it is properly initialised at
> all times.
>
> The fact that (Borland/FPC-style) Pascal is a low-level language and
> includes features like arbitrary explicit/unchecked typecasts, pointers,
> inline assembly, and that it does not force initialisation of memory with
> values that are valid for the type of the data you will store in that
> location (or even require you to define the type of a memory block when you
> allocate it), means that as a programmer you are responsible for upholding
> your end of the bargain as far as the type-safety is concerned. It's not a
> one-way street, and never has been (for not a single type).
>
> The compiler can check either statically or dynamically whether there are
> any potential errors when you implicitly convert values from one type to
> another, in case the source may contain values that are invalid for the
> target type. The programmer, on the other hand, are responsible for ensure
> that all source values are properly initialised. As mentioned before, this
> is the the garbage-in, garbage-out principle.
>
> Your argument is therefore unrelated to enum types. On the other hand, you
> are, however, correct that as far as base enums specifically are concerned,
> it does seem they should be treated like in C (i.e., as a shorthand for
> plain constant declaration). You will still have the same problem with (at
> least integer, and possibly also enum) subranges though.
>
>
> Jonas
> _______________________________________________
> fpc-devel maillist  -  fpc-devel at lists.freepascal.org
> http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freepascal.org/pipermail/fpc-devel/attachments/20170716/cbf5f677/attachment.html>