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

On Sat, 3 Aug 2019, Ondrej Pokorny wrote: On 13.07.2019 21:26, Michael Van Canneyt wrote: I think all sides have now been reviewed to the point of boring or annoying each other almost to death, and we finally need to decide on whether the patch is applied, and if so, which parts of it.

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

On 13.07.2019 21:26, Michael Van Canneyt wrote: I think all sides have now been reviewed to the point of boring or annoying each other almost to death, and we finally need to decide on whether the patch is applied, and if so, which parts of it. That would be great. I have been waiting for

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

On Tue, Jul 16, 2019 at 8:35 AM Michael Van Canneyt wrote: > 2. The Low(T) does not work, as there is no way to tell Delphi that T must > be an enum. > Hmm, I guess it makes sense Delphi wouldn't allow the "Low", based on other Delphi generics behavior (more like C#, whereas FPC is more like

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

Michael Van Canneyt schrieb am Di., 16. Juli 2019, 16:31: > > > On Tue, 16 Jul 2019, Ben Grasset wrote: > > > On Tue, Jul 16, 2019 at 5:28 AM Sven Barth via fpc-devel < > > fpc-devel@lists.freepascal.org> wrote: > > > >> The output will then be two different addresses, thus showing that the > >>

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

On Tue, 16 Jul 2019, Ben Grasset wrote: On Tue, Jul 16, 2019 at 5:28 AM Sven Barth via fpc-devel < fpc-devel@lists.freepascal.org> wrote: The output will then be two different addresses, thus showing that the code had been generated twice. However the compiler/linker is good at leaving out

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

On Tue, Jul 16, 2019 at 5:28 AM Sven Barth via fpc-devel < fpc-devel@lists.freepascal.org> wrote: > The output will then be two different addresses, thus showing that the > code had been generated twice. > > However the compiler/linker is good at leaving out unused code and in this > case only

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

On Sat, 13 Jul 2019, Ben Grasset wrote: On Sat, Jul 13, 2019 at 2:37 PM Ondrej Pokorny wrote: I do exactly the same - check the low/high bounds in a type helper :) Yes, and I am tired of typing it as well :) You can pretty easily write a generic function that will work on pretty much

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

Ben Grasset schrieb am Mo., 15. Juli 2019, 23:48: > On Mon, Jul 15, 2019 at 5:23 PM Sven Barth via fpc-devel < > fpc-devel@lists.freepascal.org> wrote: > >> That is exactly what is happening if you have a specialization in >> multiple units that don't know about each other. >> > > At what point

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

Ben Grasset schrieb am Di., 16. Juli 2019, 00:13: > On Mon, Jul 15, 2019 at 5:50 PM Michael Van Canneyt < > mich...@freepascal.org> wrote: > >> As far as I know, they are not. I believe that when specializing, the >> compiler checks if an identical specialization is in scope: >> if so, it uses

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

Michael Van Canneyt schrieb am Mo., 15. Juli 2019, 23:50: > > > On Mon, 15 Jul 2019, Ben Grasset wrote: > > > On Mon, Jul 15, 2019 at 5:23 PM Sven Barth via fpc-devel < > > fpc-devel@lists.freepascal.org> wrote: > > > >> That is exactly what is happening if you have a specialization in >

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

Nihao, On Sat, Jul 13, 2019 at 01:52:46PM +0200, Michael Van Canneyt wrote: > On Sat, 13 Jul 2019, Jonas Maebe wrote: > > On 13/07/2019 13:28, J. Gareth Moreton wrote: > > [...] > > > > Declare your enumation types so that the lowest and highest valid value > > comprise the lowest and highest

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

On Mon, Jul 15, 2019 at 5:50 PM Michael Van Canneyt wrote: > As far as I know, they are not. I believe that when specializing, the > compiler checks if an identical specialization is in scope: > if so, it uses that. If not, a duplicate is made. > > As far as I know, Delphi behaves the same. > >

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

On Mon, 15 Jul 2019, Ben Grasset wrote: On Mon, Jul 15, 2019 at 5:23 PM Sven Barth via fpc-devel < fpc-devel@lists.freepascal.org> wrote: That is exactly what is happening if you have a specialization in multiple units that don't know about each other. At what point are they being

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

On Mon, Jul 15, 2019 at 5:23 PM Sven Barth via fpc-devel < fpc-devel@lists.freepascal.org> wrote: > That is exactly what is happening if you have a specialization in multiple > units that don't know about each other. > At what point are they being removed so that the executable is not comically

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

On Mon, 15 Jul 2019, Sven Barth via fpc-devel wrote: Ben Grasset schrieb am Mo., 15. Juli 2019, 22:57: On Sat, Jul 13, 2019 at 9:02 PM Sven Barth via fpc-devel < fpc-devel@lists.freepascal.org> wrote: Not necessarily. If you have two units that don't know about each other that specialize

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

Ben Grasset schrieb am Mo., 15. Juli 2019, 22:57: > On Sat, Jul 13, 2019 at 9:02 PM Sven Barth via fpc-devel < > fpc-devel@lists.freepascal.org> wrote: > >> Not necessarily. If you have two units that don't know about each other >> that specialize the function with the same enum then you'd have

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

On Sat, Jul 13, 2019 at 9:02 PM Sven Barth via fpc-devel < fpc-devel@lists.freepascal.org> wrote: > Not necessarily. If you have two units that don't know about each other > that specialize the function with the same enum then you'd have two > specializations already. > Surely that only applies

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

> If you want to nitpick, the compiler will perform 1/2/4 byte writes for > enums of those sizes, so the full reserved data is in fact > used/initialised. Again: the only relevant part in this discussion is > the valid values. The reserved/used/accessed/written/... storage size is > unrelated to

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

On 14/07/2019 15:53, Martok wrote: > Am 14.07.2019 um 14:18 schrieb Jonas Maebe: >>> Side note: if this was done 100% consistently (and it does make sense!), the >>> PACKENUM directive would be completely useless. There is no point in being >>> able >>> to specify the storage size of an enum when

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

Am 14.07.2019 um 14:18 schrieb Jonas Maebe: >> Side note: if this was done 100% consistently (and it does make sense!), the >> PACKENUM directive would be completely useless. There is no point in being >> able >> to specify the storage size of an enum when it can be and is ignored at will. > >

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

On 14/07/2019 04:08, J. Gareth Moreton wrote: > Just a thought that I'd chuck in on this... I did wonder how practical > it would be to store checksums of all compiled procedures and the like > and to look for collisions.  When studying how the compiler is built, I > noticed a lot of the internal

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

On 14/07/2019 00:12, Martok wrote: > >> In Delphi's type system (and in C, C++, and C#), the valid values for an >> enum are always all values that fit within its storage size, and that >> storage size is fixed. >> >> In FPC's type system (and in Ada and Java), the valid values for an an >> enum

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

Am 14.07.2019 um 04:08 schrieb J. Gareth Moreton: Just a thought that I'd chuck in on this... I did wonder how practical it would be to store checksums of all compiled procedures and the like and to look for collisions.  When studying how the compiler is built, I noticed a lot of the

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

Just a thought that I'd chuck in on this... I did wonder how practical it would be to store checksums of all compiled procedures and the like and to look for collisions.  When studying how the compiler is built, I noticed a lot of the internal methods, due to conditional defines, would compile

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

Ben Grasset schrieb am Sa., 13. Juli 2019, 21:52: > On Sat, Jul 13, 2019 at 3:47 PM Michael Van Canneyt < > mich...@freepascal.org> wrote: > >> No doubt, but this will lead to a bloated binary. I want less code (both >> source and assembler), not more. >> > > Well, it would be one instantiation

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

> In Delphi's type system (and in C, C++, and C#), the valid values for an > enum are always all values that fit within its storage size, and that > storage size is fixed. > > In FPC's type system (and in Ada and Java), the valid values for an an > enum are only the values between the lowest and

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

On Sat, Jul 13, 2019 at 3:59 PM Michael Van Canneyt wrote: > Yes, I know. But the goal is to have 'is/as'. Then there is at best only 1 > helper > function for all enumerateds. > Oh yeah, I wasn't really suggesting a generic function as a *solution* to the problem versus "is" and "as". I was

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

On Sat, 13 Jul 2019, Ben Grasset wrote: On Sat, Jul 13, 2019 at 3:47 PM Michael Van Canneyt wrote: No doubt, but this will lead to a bloated binary. I want less code (both source and assembler), not more. Well, it would be one instantiation per unique type it was used on. I know. See

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

On Sat, Jul 13, 2019 at 3:47 PM Michael Van Canneyt wrote: > No doubt, but this will lead to a bloated binary. I want less code (both > source and assembler), not more. > Well, it would be one instantiation per unique type it was used on. So if you had five hand-written helper functions for

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

On Sat, 13 Jul 2019, Ben Grasset wrote: On Sat, Jul 13, 2019 at 2:37 PM Ondrej Pokorny wrote: I do exactly the same - check the low/high bounds in a type helper :) Yes, and I am tired of typing it as well :) You can pretty easily write a generic function that will work on pretty much

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

On Sat, Jul 13, 2019 at 2:37 PM Ondrej Pokorny wrote: > I do exactly the same - check the low/high bounds in a type helper :) > Yes, and I am tired of typing it as well :) > You can pretty easily write a generic function that will work on pretty much any enum for this, BTW: program Example;

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

On Sat, 13 Jul 2019, Ondrej Pokorny wrote: Even to such a degree that the compiler would simply reject your code by not allowing is/at on a variable of the type itself. Also defendable. No - not this one. Don't forget about e.g. generics: function Test(MyValue: T): Boolean; begin   Result

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

On 13.07.2019 13:47, J. Gareth Moreton wrote: Here lies the problem - if you have a enumeration stored in a byte field, say, in a file, and there's a chance it's been corrupted, there's no reliable way to detect that, since even typecasting may not be reliable, and once again I'm implying that

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

On 13.07.2019 14:32, Michael Van Canneyt wrote: I yesterday checked a database project I have. I counted 25 enumerateds which are stored in the database. Without fail, for each type there is somewhere code in a type helper: if (MyDatabaseValue>=0) and (MyDatabaseValue<=Ord(High(TMyENum)))

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

On Sat, 13 Jul 2019, Jonas Maebe wrote: On 13/07/2019 13:52, Michael Van Canneyt wrote: On Sat, 13 Jul 2019, Jonas Maebe wrote: On 13/07/2019 13:28, J. Gareth Moreton wrote: Okay, okay.  So what do we do to stop all these bug reports and help programmers who get caught out by case

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

On 13/07/2019 13:47, J. Gareth Moreton wrote: Here lies the problem - if you have a enumeration stored in a byte field, say, in a file, and there's a chance it's been corrupted, there's no reliable way to detect that, since even typecasting may not be reliable, and once again I'm implying that

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

On 13/07/2019 13:52, Michael Van Canneyt wrote: > > > On Sat, 13 Jul 2019, Jonas Maebe wrote: > >> On 13/07/2019 13:28, J. Gareth Moreton wrote: >>> Okay, okay.  So what do we do to stop all these bug reports and help >>> programmers who get caught out by case blocks raising access >>>

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

On Sat, 13 Jul 2019, Jonas Maebe wrote: On 13/07/2019 13:28, J. Gareth Moreton wrote: Okay, okay.  So what do we do to stop all these bug reports and help programmers who get caught out by case blocks raising access violations?  Are you effectively saying "don't ever use enumerations for

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

I see your point.  There seems to be some argument because it effectively bans the use of enumerations in external data (e.g. a file, network packet or third-party API) if there's a chance that the value is corrupted or has been tampered with, because sometimes allowing the program to crash is

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

On 13/07/2019 13:28, J. Gareth Moreton wrote: > Okay, okay.  So what do we do to stop all these bug reports and help > programmers who get caught out by case blocks raising access > violations?  Are you effectively saying "don't ever use enumerations for > external files and network signals" etc?

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

On 11/07/2019 15:46, J. Gareth Moreton wrote: For my personal point of view, I would like these operators to be the exception to the rule of the compiler assuming an enum always contains a valid value, As much as I would like to agree with you (and yes I think such a check, if possible,

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

Okay, okay.  So what do we do to stop all these bug reports and help programmers who get caught out by case blocks raising access violations?  Are you effectively saying "don't ever use enumerations for external files and network signals" etc? Gareth aka. Kit --- This email has been checked

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

On 11/07/2019 15:46, J. Gareth Moreton wrote: > Outside of typecasting, there isn't a reliable way to check if an enum > contains a valid value Typecasting is not a reliable way. There is no and cannot be a reliable way, period. > For my personal point of view, I would like these operators to be

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

On 11/07/2019 13:07, Michael Van Canneyt wrote: There is no "disagreement". just doubt as to what the right approach is. If the compiler assumes that an enumerated always contains a valid value, then the logical consequence is that the above "is" always evaluates to true. In that case it makes

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

On Thu, 11 Jul 2019, J. Gareth Moreton wrote: On 11/07/2019 11:52, Ondrej Pokorny wrote: BTW, your note in the issue report is very misleading: https://bugs.freepascal.org/view.php?id=33603#c117162. > The idea behind "is" and "as" is that they are the sole exception to the rule and will

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

On 11/07/2019 11:52, Ondrej Pokorny wrote: BTW, your note in the issue report is very misleading: https://bugs.freepascal.org/view.php?id=33603#c117162. > The idea behind "is" and "as" is that they are the sole exception to the rule and will return False and raise an error respectively if the

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

On 11.07.2019 11:58, J. Gareth Moreton wrote: Done! Thank you for your work! BTW, your note in the issue report is very misleading: https://bugs.freepascal.org/view.php?id=33603#c117162. > The idea behind "is" and "as" is that they are the sole exception to the rule and will return False

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

Done! On 11/07/2019 07:51, Michael Van Canneyt wrote: On Thu, 11 Jul 2019, J. Gareth Moreton wrote: Should I modify the patch to allow enumerations with holes with "is" and "as"?  Note that these operators will return True/not raise an error if a value falls within a hole but is otherwise

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

On Thu, 11 Jul 2019, J. Gareth Moreton wrote: Should I modify the patch to allow enumerations with holes with "is" and "as"?  Note that these operators will return True/not raise an error if a value falls within a hole but is otherwise between the lowest and highest elements. IMO, yes.

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

Should I modify the patch to allow enumerations with holes with "is" and "as"?  Note that these operators will return True/not raise an error if a value falls within a hole but is otherwise between the lowest and highest elements. Gareth aka. Kit On 09/07/2019 20:19, J. Gareth Moreton wrote:

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

Hopefully we'll get there in the end!  I've updated what I can in the patch file directly, so hopefully all is well now. Some of the variable names, like "ProcName", were already named as such. Gareth aka. Kit On 09/07/2019 10:12, Sven Barth via fpc-devel wrote: J. Gareth Moreton

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

J. Gareth Moreton schrieb am Di., 9. Juli 2019, 08:20: > Apologies - I see now... I used them with "with" without even thinking > about it! I've made the changes as requested. Admittedly it's quite > hard for me to remove spaces from either side of operators because > that's something I learnt

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

Apologies - I see now... I used them with "with" without even thinking about it!  I've made the changes as requested. Admittedly it's quite hard for me to remove spaces from either side of operators because that's something I learnt from my early days in Turbo Pascal and to not have spaces

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

I don't recall using "as" or "is" directly, but if I've done so, I humbly apologise and will fix that right away. Gareth aka. Kit On 09/07/2019 06:41, Sven Barth via fpc-devel wrote: Am 08.07.2019 um 02:52 schrieb J. Gareth Moreton: On an extra note, the assembly language produced is not yet

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

Sven Barth schrieb am Di., 9. Juli 2019, 07:41: > Am 08.07.2019 um 02:52 schrieb J. Gareth Moreton: > > On an extra note, the assembly language produced is not yet optimal, > > so it may end up that an x86-specific implementation will be > > beneficial. TIsNode contains a virtual method named >

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

Am 08.07.2019 um 02:52 schrieb J. Gareth Moreton: On an extra note, the assembly language produced is not yet optimal, so it may end up that an x86-specific implementation will be beneficial.  TIsNode contains a virtual method named "DoVariableEnumCheck" that would allow such an extension,

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

I need to know exactly what's been decided upon.  No arguments, no debates, no objections.  What has been accepted as "this is what will be implemented after all parties have been heard"? Because I can't put myself into a meltdown while my neck is being wrung for not doing what people wanted.

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

Apologies.  I've been getting lost and confused in all the details and am not even sure what people want any more.  What is the consensus from the administrators? Gareth aka. Kit On 08/07/2019 21:00, Ondrej Pokorny wrote: On 08.07.2019 17:19, J. Gareth Moreton wrote: I disabled it after

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

On 08.07.2019 17:19, J. Gareth Moreton wrote: I disabled it after Pierre pointed out that you couldn't use Pred or Succ with them, so wanted to be consistent, especially as programming them to return the expected value of False of a value falls within a hole is not simple. Still, it's easy

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

I disabled it after Pierre pointed out that you couldn't use Pred or Succ with them, so wanted to be consistent, especially as programming them to return the expected value of False of a value falls within a hole is not simple. Still, it's easy enough to re-enable. Gareth aka. Kit On Mon

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

On 08.07.2019 02:37, J. Gareth Moreton wrote: Uploaded the latest patch (AS-IS-enum-07.patch) over here and also a test project that evaluates the "is" operator between different ordinal types. I though I convinced you not to disable the

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

On 08.07.2019 12:39, Giuliano Colla wrote: Il 07/07/2019 07:33, J. Gareth Moreton ha scritto: 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

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

Il 07/07/2019 07:33, J. Gareth Moreton ha scritto: 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

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

On an extra note, the assembly language produced is not yet optimal, so it may end up that an x86-specific implementation will be beneficial.  TIsNode contains a virtual method named "DoVariableEnumCheck" that would allow such an extension, coupled with returning "nil" that would defer code

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

Uploaded the latest patch (AS-IS-enum-07.patch) over here and also a test project that evaluates the "is" operator between different ordinal types. Following the advice of Jonas and Florian, I've removed my x86-specific code for now. Gareth

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

Oh right!  In that case, I can upload the code now... well, after I finish testing everything!  (I'll keep my platform-specific code in a personal branch though in case it doesn't work). I have seen once source of inefficiency in the compiled assembly language and that's something akin to

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

On 07/07/2019 07:33, J. Gareth Moreton wrote: > 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

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

Most of it is node-level.  Ondrej's method was to use an inlined compilerproc to do the range check, but the parameters are of type SizeInt, which causes problems if the range to check against is of size Int64 or, worse, QWord.  It may be that after some refactoring, the nodes for such an

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

Am 07.07.2019 um 07:33 schrieb 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

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

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

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

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 >

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

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

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

On Sat, 6 Jul 2019, Ondrej Pokorny wrote: On 05.07.2019 22:44, J. Gareth Moreton wrote: In the meantime, I've extended your AS/IS patch over here to create efficient code for x86 platforms, although currently it only does a range check and

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

On 05.07.2019 22:44, J. Gareth Moreton wrote: In the meantime, I've extended your AS/IS patch over here to create efficient code for x86 platforms, although currently it only does a range check and won't correctly handle enumerations with

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

On 06.07.2019 02:10, Martok wrote: In that case, unlike what was previously said in this thread, this should simply work: generic function TStreamHelper.ReadEnum(out aEnum: T): Boolean; begin if Read(aEnum, SizeOf(aEnum)) <> SizeOf(aEnum) then Exit(False) else begin Result :=

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

On Fri, 5 Jul 2019 00:40:15 +0100 "J. Gareth Moreton" wrote: > You could consider this an ultimatum, but I know it will be pointless > to do that because you'll just ignore me.  So I'm pleading, Jonas... > there needs to be a way to check if an enumeration contains an > invalid value to avoid

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

Am 06.07.2019 um 01:21 schrieb J. Gareth Moreton: > According to this , > a > Longint. Ah, right. I checked the source again: that is true only if the argument is an enum. If it is any other ordinal type or Pointer, the result is of the

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

On 05/07/2019 23:50, Sven Barth via fpc-devel wrote: Am 05.07.2019 um 22:34 schrieb J. Gareth Moreton: It feels like a very convoluted way to implement a safe means of reading an enumeration from a file, but given that that reading incorrect data files is one of the main causes of enums

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

According to this , a Longint. Gareth aka. Kit On 06/07/2019 00:04, Martok wrote: I think there is a shorter version, but what is the exact return type of Ord() again? By the way, what you're reinventing here is type marshalling, for

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

I think there is a shorter version, but what is the exact return type of Ord() again? By the way, what you're reinventing here is type marshalling, for one single type class, and in a very roundabout way. If that is really what the discussion settled on, it would probably make sense to not tack

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

Am 05.07.2019 um 22:34 schrieb J. Gareth Moreton: It feels like a very convoluted way to implement a safe means of reading an enumeration from a file, but given that that reading incorrect data files is one of the main causes of enums taking on invalid values, I have to say that this is the

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

In the meantime, I've extended your AS/IS patch over here to create efficient code for x86 platforms, although currently it only does a range check and won't correctly handle enumerations with holes.  If non-contiguous enumerations are going to

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

It feels like a very convoluted way to implement a safe means of reading an enumeration from a file, but given that that reading incorrect data files is one of the main causes of enums taking on invalid values, I have to say that this is the best solution should we not be allowed the "is"

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

Am 05.07.2019 um 22:25 schrieb Sven Barth: Am 05.07.2019 um 08:08 schrieb Sven Barth: Jonas Maebe 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

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

Am 05.07.2019 um 08:08 schrieb Sven Barth: Jonas Maebe 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

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

On 05.07.2019 16:51, Pierre Muller wrote: This means that using pred() or succ() intrinsics on enumerated types with holes will generate a Compile Time Error. To be consistent, I would propose that we also generate a Compile Time Error if 'is' or 'as' keyword is used on such a type, unless

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

Hey there - sorry if I'm not explaining myself too well. My question would be this... if Value is a variable of type TEnum that is invalid (either because it is out of range or contains a 'hole' value, but more specifically the former), should "Value is TEnum" return True, False or an

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

Pierre Muller schrieb am Fr., 5. Juli 2019, 17:51: > > > Le 05/07/2019 à 17:42, J. Gareth Moreton a écrit : > > > > On 05/07/2019 15:51, Pierre Muller wrote: > >> Just one point from current compiler implementation: > >> > >> in trunk/fpcsrc/compiler/ninl.pas (around line 3180) > >> > >>

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

Le 05/07/2019 à 17:42, J. Gareth Moreton a écrit : > > On 05/07/2019 15:51, Pierre Muller wrote: >> Just one point from current compiler implementation: >> >> in trunk/fpcsrc/compiler/ninl.pas (around line 3180) >> >>in_pred_x, >>in_succ_x: >>

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

On 05/07/2019 15:51, Pierre Muller wrote: Just one point from current compiler implementation: in trunk/fpcsrc/compiler/ninl.pas (around line 3180) in_pred_x, in_succ_x: begin set_varstate(left,vs_read,[vsf_must_be_valid]);

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

Martok schrieb am Fr., 5. Juli 2019, 14:54: > Am 05.07.2019 um 14:24 schrieb Sven Barth via fpc-devel: > > Huh? The comment regarding dynamic packages is nonsense. The compiler > and RTL > > check that the checksums of the involved interface sections match and > thus there > > is no problem

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

On 05.07.2019 16:51, Pierre Muller wrote: Just one point from current compiler implementation: in trunk/fpcsrc/compiler/ninl.pas (around line 3180) in_pred_x, in_succ_x: begin set_varstate(left,vs_read,[vsf_must_be_valid]);

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

Just one point from current compiler implementation: in trunk/fpcsrc/compiler/ninl.pas (around line 3180) in_pred_x, in_succ_x: begin set_varstate(left,vs_read,[vsf_must_be_valid]); resultdef:=left.resultdef;

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

On 05.07.2019 14:58, Martok wrote: Am 05.07.2019 um 12:20 schrieb Ondrej Pokorny: Anything that even looks like a subrange cannot be used for these interfaces. You may use enumerations for these interfaces - you may just not fill them directly but through an integer variable in between when

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

On 05.07.2019 14:58, Martok wrote: Am 05.07.2019 um 12:20 schrieb Ondrej Pokorny: Anything that even looks like a subrange cannot be used for these interfaces. You may use enumerations for these interfaces - you may just not fill them directly but through an integer variable in between when

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

On 05/07/2019 13:29, Sven Barth via fpc-devel wrote: J. Gareth Moreton > schrieb am Fr., 5. Juli 2019, 14:02: I'm glad we agree on the "is" operator.  Personally I would like to extend it so it accepts "if (I is TMyEnum) then" when I is also of type

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

> But I will not argue the point, it is largely a matter of personal > interpretation > of the intended use of an enumerated. Well, yes. Since any argument from authority is discarded, what remains is personal interpretation. > But I will definitely adapt the FPC documentation to be more clear

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

Am 05.07.2019 um 11:28 schrieb Michael Van Canneyt: > But IMO such a strict stance is untenable: you cannot ensure correct values > in all cases even within the confines of the language (as demonstrated > before). Correct. Even if certain (exactly two) people here believe differently. > So,

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

Am 05.07.2019 um 12:20 schrieb Ondrej Pokorny: >> Anything that even looks like a subrange cannot be used for these interfaces. > > You may use enumerations for these interfaces - you may just not fill > them directly but through an integer variable in between when reading > from outside. Then

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

Am 05.07.2019 um 14:24 schrieb Sven Barth via fpc-devel: > Huh? The comment regarding dynamic packages is nonsense. The compiler and RTL > check that the checksums of the involved interface sections match and thus > there > is no problem there. Does that cascade? If so, that's better than

  1   2   >