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

[J. Gareth Moreton]

Maybe I'm missing something painfully 
obvious here. Can I request an example 
where such an invalid value/undefined 
behaviour crops up in bitpacked records so 
I can see what's going on? Logic dictates 
that the number of bits required to store 
an enum in that arrangement is equal to 
the index of the highest element, although 
that's without looking at the source code 
and doesn't account for elements that have 
assigned negative values.

In the meantime, I'm working on making 
"as" and "is" work with ordinal types as 
well as enumerations, although currently 
some headaches occur if the right-hand 
side is larger than the CPU word size 
(e.g. Int64 on i386). I'll upload the 
patch to the issue once it's working 
properly.

Gareth aka. Kit

On Sat 06/07/19 14:19 , "Jonas Maebe" 
jonas at freepascal.org sent:
> On 06/07/2019 14:56, Martok wrote:
> 
> > Am 06.07.2019 um 09:01 schrieb Ondrej 
Pokorny:
> 
> >> Ord(aEnum) for invalid enumeration 
values is
> undefined ;)
> > 
> 
> > If there was any logic here, it should 
be, but
> it's not ;-)
> > 
> 
> > The documentation page specifically 
mentions Ord
> as the older syntax to hard
> > casts. Whatever it contains, any enum 
is always
> smaller or equal to the largest
> > possible bitsize, which is Longint.
> 
> 
> 
> It is in fact undefined. The undefined 
behaviour comes from the fact
> 
> that an invalid value was stored in the 
variable and then read again,
> 
> not from how the read value is used. An 
example of where you may get
> 
> different data than wat you put in, even 
in the absence of any
> 
> optimisations, is again bitpacked 
records/arrays.
> 
> 
> 
> 
> 
> Jonas
> 
> 
__________________________________________
_____
> 
> fpc-devel maillist  -  fpc-
devel at lists.freepascal.org
> https://lists.freepascal.org/cgi-
bin/mailman/listinfo/fpc-devel
> 
> 
> 
> 
>