Am 05.07.2019 um 22:25 schrieb Sven Barth:
Am 05.07.2019 um 08:08 schrieb Sven Barth:
Jonas Maebe <jo...@freepascal.org <mailto:jo...@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
_______________________________________________
fpc-devel maillist - fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
