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" jo...@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- de...@lists.freepascal.org > https://lists.freepascal.org/cgi- bin/mailman/listinfo/fpc-devel > > > > > _______________________________________________ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel