[fpc-devel] [Suggestion] Enumeration range-check intrinsic

[Sven Barth]

Am 05.07.2019 um 22:25 schrieb Sven Barth:
> Am 05.07.2019 um 08:08 schrieb Sven Barth:
>> Jonas Maebe <jonas at freepascal.org <mailto:jonas at freepascal.org>> 
>> schrieb am Do., 4. Juli 2019, 21:21:
>>
>>     On 03/07/2019 09:26, Ondrej Pokorny wrote:
>>     > On 02.07.2019 23:34, Jonas Maebe wrote:
>>     >> Invalid data means undefined behaviour, always. "is" is not a
>>     special
>>     >> case that is immune to this.
>>     >
>>     > Don't you really see the need to handle invalid data with a
>>     /defined/
>>     > behavior?
>>
>>     My point is that is impossible to do so, so trying to do it in a way
>>     that works in some/most cases, is much more dangerous than
>>     categorically
>>     refusing to try to do it, as it creates a false sense of security.
>>
>>
>> Then how would you read data from e.g. a stream into an enum or 
>> subrange if the stream may contain invalid data?
> I now did a proof of concept for that task myself:
>
> === code begin ===
>
[snip]
> if not s.specialize ReadEnum<TMyEnum>(e) then
>         raise EStreamError.Create('Failed to read enum value');
>       Writeln('Read value: ', e);
>       if not s.specialize ReadEnum<TMyEnum>(e) then
>         raise EstreamError.CReate('Failed to read enum value');
[snip]
>
> === code end ===

Oh and once I've integrated Ryan's implicit specialization support the 
code can become this (or at least I hope so ^^'):

=== code begin ===
       if not s.ReadEnum(e) then
         raise EStreamError.Create('Failed to read enum value');
       Writeln('Read value: ', e);
       if not s.ReadEnum(e) then
         raise EstreamError.CReate('Failed to read enum value');

=== code end ===

Regards,
Sven
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freepascal.org/pipermail/fpc-devel/attachments/20190705/9f0273d5/attachment-0001.html>