Re: [fpc-devel] Deeper problem with Internal Error 200309201

So having a long think over the past day, I'm starting to turn against the second idea I had because it would require complex state variable tracking and is just asking for a new bug to be introduced, not to mention that the additional overhead will probably offset any potential speed gains, so

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 p

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 jus

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 b

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 dif

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 any

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))) then

Re: [fpc-devel] Deeper problem with Internal Error 200309201

P.S. I would like Florian's approval before I start anything though, because as I've learnt with my inline assembler work, I'll just end up getting upset, melting down and burning out. Gareth aka. Kit --- This email has been checked for viruses by Avast antivirus software. https://www.avast.c

Re: [fpc-devel] Deeper problem with Internal Error 200309201

Points seem fair so far.  And true, the Boolean result won't be necessary because the error flag will be set, and this can be checked instead. While the idea behind "pass_1" and "simplify" are different, to me it isn't always clear what is simplification and what is regular code pass, and is

Re: [fpc-devel] FPC 3.0.4 ld error on opensuse 13.2

Hi, 09.07.2019 22:32, Florian Klämpfl: /usr/bin/ld: /usr/lib64/fpc/3.0.4/units/x86_64-linux/rtl/prt0.o: unrecognized relocation (0x2a) in section `.text' [...] As windows uses a different binary format, it is not possible to judge from windows to linux. I am pretty convinced, a newer ld migh

Re: [fpc-devel] Deeper problem with Internal Error 200309201

Am 13.07.2019 um 14:12 schrieb J. Gareth Moreton: I would like some discussion on this with the administrative team because this does require some careful design if we're going to do this properly.  Building on Florian's suggestion, I would like to propose splitting "pass_1" into "pass_syntax"

Re: [fpc-devel] Move operator

> On Jul 13, 2019, at 8:21 AM, Jonas Maebe wrote: > > In which scenarios do you need such a custom "move" operator, rather > than simply allowing the compiler to just copy the data from one place > to the other without calling a destructor on the old instance? Not sure off the top of my head w

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 blocks

Re: [fpc-devel] Move operator

On 10/07/2019 22:36, Ryan Joseph wrote: > So I've started using the record management operators in earnest and see a > real need for another “Move” operator in order to prevent the constant > unnecessary copies. If you look at the example in the bug report you’ll see > where adding a Move operat

[fpc-devel] Deeper problem with Internal Error 200309201

Hi everyone, So my patch to fix #32913 was unfortunately rejected because it relied on a slightly hacky feature in the form of a new state variable that, currently, is only used to patch this particular issue, and as Florian has hinted in the is

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 >>> violation

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 exte

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, wou

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