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

[J. Gareth Moreton]

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freepascal.org/pipermail/fpc-devel/attachments/20190703/50b2fd58/attachment.html>