On 03/07/2019 01:13, Ondrej Pokorny wrote:
On 02.07.2019 23:34, Jonas Maebe wrote:
As to your patch itself: why do you not directly compare the
tconstexprint values directly, and use the svalue/uvalue fields instead?
Because I missed that they can be directly compared directly.
I dare say, I would advise you make any new changes to my
"AS-IS-enum-04.patch", since that adds an internal error to one of the
case blocks (mostly to suppress a compiler warning) and ensures it
merges cleanly with the trunk.
I am with you that we need /something/ to determine if an enumeration is
in range or not because of the common problem of reading from a file.
Invalid data happens - to actually enforce that all behaviour is
undefined is VERY bad practice. There are some applications where the
program must be able to handle and recover erroneous inputs, and a data
file is one such source of errors - for example, a program writes an
enumeration to a file, and in a later version of the program, you add a
new value to the enumeration, and then try to read that file in the old
version of the program. You could argue that it was a poor design
choice to not include a version field so you don't read such a value in
the first place, but it's too late to change that, and it still doesn't
trap the case where the file has been deliberately modified in an
attempt to crash the program. If a developer wishes to make their
software robust, we have no right to forbid it. Honestly, it just
discourages the language's use.
The "as" and "is" operators are the only 'exceptions' to the language
that would be required here. Range checks need not be included in other
conditions, and a single exception can be documented.
Gareth aka. Kit
---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus
_______________________________________________
fpc-devel maillist - fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
