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

[Tomas Hajny]

On Sun, July 2, 2017 17:05, Michael Van Canneyt wrote:
> On Sun, 2 Jul 2017, Tomas Hajny wrote:
>
>> On Sun, July 2, 2017 16:48, Marco van de Voort wrote:
>>> In our previous episode, Martok said:
>>>> It is really hard to write code that interacts with the outside world
>>>> without
>>>> having a validation problem.
>>>
>>> Then you arguing wrong. Then you don't need validation everywhere, but
>>> something you can call to simply confirm an enum has correct values
>>> after
>>> reading.
>>>
>>> It is not logical to have heaps of checks littered everywhere if the
>>> corruption happens in a defined place (on load).
>>>
>>> Worse, tying it to range check would then have heaps of redundant
>>> checking
>>> everywhere, not just enums.
>>
>> True. That's why I believe that Read from a (typed) file should perform
>> such validation - but it doesn't at the moment, as mentioned in my
>> e-mail
>> in the other thread. :-(
>
> IMHO it should not.
>
> By declaring it as a File of Enum, you are telling the compiler that it
> contains only valid enums.

Noone can ever ensure, that a file doesn't get corrupted / tampered with
on a storage medium. In other words, you cannot check your assumption
mentioned above earlier than while reading the file. In this logic, typed
files could never be used in any program, because noone could ever ensure
that these files conform to their stated type before their contents enters
a variable of the declared type (and it should be validated before that
point, because that's exactly the point at which the compiler and possibly
also your program start assuming type safety).

Moreover, using the same Read for reading from a text file _does_ perform
such checks (e.g. when using Read for reading an integer from a text file,
the value read is validated whether it conforms the given type and
potential failures are signalized either as an RTE, or a non-zero IOResult
depending on the $I state).

Tomas