Re: [fpc-devel] Dangerous optimization in CASE..OF

On 22.04.2018 10:46, Luca Olivetti wrote: El 22/04/18 a les 06:53, Ondrej Pokorny ha escrit: My goal is to get the best from it. If disallowing of IS/AS for enums with holes in FPC modes is a requirement for applying the patch, I am OK with this sacrifice. Why disallow it instead of simply

Re: [fpc-devel] Dangerous optimization in CASE..OF

El 22/04/18 a les 06:53, Ondrej Pokorny ha escrit: My goal is to get the best from it. If disallowing of IS/AS for enums with holes in FPC modes is a requirement for applying the patch, I am OK with this sacrifice. Why disallow it instead of simply checking if it's one of the valid values?

Re: [fpc-devel] Dangerous optimization in CASE..OF

On 21.04.2018 13:38, Martok wrote: Am 20.04.2018 um 21:35 schrieb Ondrej Pokorny: Therefore I enabled the IS/AS operators on enums with holes only in Delphi mode and disabled them in all other modes. Please do not do this. The other modes are the only ones that really need it, in Delphi mode,

Re: [fpc-devel] Dangerous optimization in CASE..OF

Am 21.04.2018 um 16:40 schrieb Alexander Grotewohl: > To be honest I agree with what he's saying. We're bending enums to do > things normal people just wouldn't (and shouldn't) do. No, we don't. There are two semantically different sorts of enums: if you want an enum to contain only the named

Re: [fpc-devel] Dangerous optimization in CASE..OF

Alexander Grotewohl schrieb am Sa., 21. Apr. 2018, 16:40: > To be honest I agree with what he's saying. We're bending enums to do > things normal people just wouldn't (and shouldn't) do. > > And seriously, "Delphi, Delphi, Delphi!" .. why don't we strive for > something a

Re: [fpc-devel] Dangerous optimization in CASE..OF

ay than us their way. Alex On 04/21/2018 08:12 AM, Thorsten Engler wrote: -Original Message- From: fpc-devel <fpc-devel-boun...@lists.freepascal.org> On Behalf Of Martok Sent: Saturday, 21 April 2018 21:39 To: fpc-devel@lists.freepascal.org Subject: Re: [fpc-devel] Dangerous opti

Re: [fpc-devel] Dangerous optimization in CASE..OF

lists.freepascal.org > > Subject: Re: [fpc-devel] Dangerous optimization in CASE..OF > > > > Am 20.04.2018 um 21:35 schrieb Ondrej Pokorny: > > > Sven (or anybody else), could you please comment on > > > https://bugs.freepascal.org/view.php?id=33603 ? I feel I am

Re: [fpc-devel] Dangerous optimization in CASE..OF

> -Original Message- > From: fpc-devel <fpc-devel-boun...@lists.freepascal.org> On Behalf Of > Martok > Sent: Saturday, 21 April 2018 21:39 > To: fpc-devel@lists.freepascal.org > Subject: Re: [fpc-devel] Dangerous optimization in CASE..OF > > Am 20.04.2018 u

Re: [fpc-devel] Dangerous optimization in CASE..OF

Am 20.04.2018 um 21:35 schrieb Ondrej Pokorny: > Sven (or anybody else), could you please comment on > https://bugs.freepascal.org/view.php?id=33603 ? I feel I am getting crazy. That bug became a textbook example of Cipolla's fourth law, sorry. > From what I read, there seems to be a difference

Re: [fpc-devel] Dangerous optimization in CASE..OF

On 13.04.2018 23:16, Sven Barth via fpc-devel wrote: Ondrej Pokorny > schrieb am Fr., 13. Apr. 2018, 21:16: On 13.04.2018 14:08, Sven Barth via fpc-devel wrote: Ondrej Pokorny > schrieb am

Re: [fpc-devel] Dangerous optimization in CASE..OF

On 15.04.2018 19:46, Martok wrote: Am 15.04.2018 um 11:09 schrieb Ondrej Pokorny: Please note that I want to support all ordinal values on the left side of the operator. You can then validate a value of variable of the enum type itself. Useful indeed! It still strikes me as weird that one will

Re: [fpc-devel] Dangerous optimization in CASE..OF

Am 15.04.2018 um 11:09 schrieb Ondrej Pokorny: > Please note that I want to support all ordinal values on the left side > of the operator. You can then validate a value of variable of the enum > type itself. Useful indeed! It still strikes me as weird that one will need to add this check many

Re: [fpc-devel] Dangerous optimization in CASE..OF

On 15.04.2018 0:05, Martok wrote: All this is not quite as easy to get right as it seems on the surface. But I do like the the "v is TEnum" operator from the other side of this thread, regardless of where this goes... I don't want to force FPC to any direction. I just want to have a simple

Re: [fpc-devel] Dangerous optimization in CASE..OF

Regarding things to be documented in Delphi: As was established last year, this aspect of FPCs type system is intended to be a bit more strict than that of the Hejlsberg languages (*), so I'm not taking anything for granted any more. (Case in point, while I see it: the very different role of range

Re: [fpc-devel] Dangerous optimization in CASE..OF

/... > If i is TEnum then >//... > If i is SmallInt then >//... > > (same with "as"). > > > >> -Original Message- >> From: fpc-devel <fpc-devel-boun...@lists.freepascal.org> On Behalf >> Of Ondrej Pokorny >>

Re: [fpc-devel] Dangerous optimization in CASE..OF

On Behalf > Of Ondrej Pokorny > Sent: Saturday, 14 April 2018 19:03 > To: fpc-devel@lists.freepascal.org > Subject: Re: [fpc-devel] Dangerous optimization in CASE..OF > > On 14.04.2018 10:39, Thorsten Engler wrote: > > How about following the same schema as with classes?

Re: [fpc-devel] Dangerous optimization in CASE..OF

On 14.04.2018 10:39, Thorsten Engler wrote: How about following the same schema as with classes? If 1 is TMyEnum then //use hard cast here Yes, that is reasonable as well and it will be easier to implement than the TryIntToEnum/IntToEnum intrinsics for me. Ondrej

Re: [fpc-devel] Dangerous optimization in CASE..OF

@lists.freepascal.org > Subject: Re: [fpc-devel] Dangerous optimization in CASE..OF > > On 14.04.2018 10:24, Michael Van Canneyt wrote: > > On Sat, 14 Apr 2018, Ondrej Pokorny wrote: > > > >> Effectively, you should be able to use: > >> var > >> E: TM

Re: [fpc-devel] Dangerous optimization in CASE..OF

On 14.04.2018 10:24, Michael Van Canneyt wrote: On Sat, 14 Apr 2018, Ondrej Pokorny wrote: Effectively, you should be able to use: var   E: TMyEnum; begin   if TryIntToEnum(1, E) then instead of   if TryIntToEnum(TMyEnum, 1, E) then I am all for it, although I think the "as" syntax is more

Re: [fpc-devel] Dangerous optimization in CASE..OF

On Sat, 14 Apr 2018, Ondrej Pokorny wrote: On 14.04.2018 9:59, Michael Van Canneyt wrote: On Sat, 14 Apr 2018, Ondrej Pokorny wrote: On 02.07.2017 18:49, Jonas Maebe wrote: I would be in favour of a new intrinsic. I have to admit that for some usages I would prefer a compiler

Re: [fpc-devel] Dangerous optimization in CASE..OF

On 14.04.2018 9:59, Michael Van Canneyt wrote: On Sat, 14 Apr 2018, Ondrej Pokorny wrote: On 02.07.2017 18:49, Jonas Maebe wrote: I would be in favour of a new intrinsic. I have to admit that for some usages I would prefer a compiler intrinsic that returns False instead of raising an

Re: [fpc-devel] Dangerous optimization in CASE..OF

On Sat, 14 Apr 2018, Ondrej Pokorny wrote: On 02.07.2017 18:49, Jonas Maebe wrote: I would be in favour of a new intrinsic. I have to admit that for some usages I would prefer a compiler intrinsic that returns False instead of raising an exception. Something like: function

Re: [fpc-devel] Dangerous optimization in CASE..OF

On 02.07.2017 18:49, Jonas Maebe wrote: I would be in favour of a new intrinsic. I have to admit that for some usages I would prefer a compiler intrinsic that returns False instead of raising an exception. Something like: function TryIntToEnum(const AValue: Integer; var AEnumValue: T):

Re: [fpc-devel] Dangerous optimization in CASE..OF

On 13.04.2018 23:16, Sven Barth via fpc-devel wrote: I wasn't talking about the boundaries. I meant undefined values inside the enum. If we want such a cast operator to work with such enums as well it should check for invalid values inside the enum, too. Otherwise the operator isn't worth it

Re: [fpc-devel] Dangerous optimization in CASE..OF

Ondrej Pokorny schrieb am Fr., 13. Apr. 2018, 21:16: > On 13.04.2018 14:08, Sven Barth via fpc-devel wrote: > > Ondrej Pokorny schrieb am Fr., 13. Apr. 2018, 12:52: > >> I introduced the AS operator for enumerations in >>

Re: [fpc-devel] Dangerous optimization in CASE..OF

On 13.04.2018 14:08, Sven Barth via fpc-devel wrote: Ondrej Pokorny > schrieb am Fr., 13. Apr. 2018, 12:52: I introduced the AS operator for enumerations in https://bugs.freepascal.org/view.php?id=33603 What about enums with holes? No

Re: [fpc-devel] Dangerous optimization in CASE..OF

Am 13.04.2018 um 12:52 schrieb Ondrej Pokorny: > I introduced the AS operator for enumerators in > https://bugs.freepascal.org/view.php?id=33603 I'm still not convinced that cementing the FPC-ism of Ada-style high-level enums is a good idea (and how that is even logically supposed to work with

Re: [fpc-devel] Dangerous optimization in CASE..OF

On Fri, 13 Apr 2018, Ondrej Pokorny wrote: On 02.07.2017 18:55, Ondrej Pokorny wrote: On 02.07.2017 18:49, Jonas Maebe wrote: No, there is no built-in checked conversion from integer to arbitrary enumeration types. That's why I suggested in the bug report that started this thread to file a

Re: [fpc-devel] Dangerous optimization in CASE..OF

On 02.07.2017 18:55, Ondrej Pokorny wrote: On 02.07.2017 18:49, Jonas Maebe wrote: No, there is no built-in checked conversion from integer to arbitrary enumeration types. That's why I suggested in the bug report that started this thread to file a feature request for such a conversion. Very

Re: [fpc-devel] Dangerous optimization in CASE..OF

On 04/10/17 08:15, Martok wrote: Hi all, another few months, and something funny happened this morning: a tweet shows upin my timeline which links to this article on efficient codegen for dispatchwith switch statements:Very

Re: [fpc-devel] Dangerous optimization in CASE..OF

Hi all, another few months, and something funny happened this morning: a tweet shows up in my timeline which links to this article on efficient codegen for dispatch with switch statements: Very interesting! Why I'm

Re: [fpc-devel] Dangerous optimization in CASE..OF

Am 25.07.2017 um 19:31 schrieb Martok: > As has just been pointed out to me, we all misdiagnosed that example. Turns out this is not a new question, there is actually a very thorough treatment of that very issue on SO:

Re: [fpc-devel] Dangerous optimization in CASE..OF

As has just been pointed out to me, we all misdiagnosed that example. TL;DR: you did test undefined behaviour, only a different one. The example actually proves that clang and gcc agree with the MSDN article in that (even simple) C++ enums are low-level. I have verified that Clang/LLVM

Re: [fpc-devel] Dangerous optimization in CASE..OF

Martok wrote: > I would think that > type > TEnum = (a,b,c); > TSubEnum = a..c; > > should have the same semantics, but at the same time they can't if subranges > are > strict and enums are not. I see now where you're coming from. > (I'll get back to that example at the end.) > > And then

Re: [fpc-devel] Dangerous optimization in CASE..OF

> OK, I see now: there is a difference between C enums and C++ enums. Your > example was about C++ enums. My example was about C enums. The C enums > are defined to allow any integer value, whereas C++ enums are strongly > typed. In the pages cited, there's no mention of valid ranges, only that

Re: [fpc-devel] Dangerous optimization in CASE..OF

On 16.07.2017 21:13, Florian Klaempfl wrote: Indeed. This proves the exactly point. Undefined behaviour. The code behaves randomly dependent on the compiler used and even the optimizer switches. OK, I see now: there is a difference between C enums and C++ enums. Your example was about C++

Re: [fpc-devel] Dangerous optimization in CASE..OF

On 16.07.2017 23:11, Florian Klämpfl wrote: Am 16.07.2017 um 22:39 schrieb Florian Klämpfl: Am 16.07.2017 um 22:15 schrieb Martok: However: --- {$mode objfpc} type TExplEnum = (a=1, b=3, c=5, d=7); TSubEnum = a..d; TEnArr = array[TSubEnum] of Byte; begin

Re: [fpc-devel] Dangerous optimization in CASE..OF

Am 16.07.2017 um 22:39 schrieb Florian Klämpfl: > Am 16.07.2017 um 22:15 schrieb Martok: >> >> However: >> --- >> {$mode objfpc} >> type >> TExplEnum = (a=1, b=3, c=5, d=7); >> TSubEnum = a..d; >> TEnArr = array[TSubEnum] of Byte; >> >> begin >>

Re: [fpc-devel] Dangerous optimization in CASE..OF

Am 16.07.2017 um 22:15 schrieb Martok: > > However: > --- > {$mode objfpc} > type > TExplEnum = (a=1, b=3, c=5, d=7); > TSubEnum = a..d; > TEnArr = array[TSubEnum] of Byte; > > begin > WriteLn('SizeOf(TEnArr) = ', SizeOf(TEnArr)); > WriteLn('Low(TEnArr) = ',

Re: [fpc-devel] Dangerous optimization in CASE..OF

Am 16.07.2017 um 13:17 schrieb Jonas Maebe: > Does that mean that you would consider the same transformation of a > case-statement when using a subrange type as correct? And that putting a > value outside the range of a subrange into such a variable as a > programmer error? (as opposed to doing

Re: [fpc-devel] Dangerous optimization in CASE..OF

You (Florian) do realize that it's almost impossible to write a C++ program that is not technically undefined? Their 'standards' are worse than our 'implementation-defined'. FWIW, GCC agrees with Low-Level Enums, and given that clang regularly catches hate when their 'optimizations' break stuff

Re: [fpc-devel] Dangerous optimization in CASE..OF

Am 16.07.2017 um 19:58 schrieb Ondrej Pokorny: > On 16.07.2017 19:24, Martok wrote: >> The good thing about case statements is that they tell me of every other >> programmer error: missing elements (if used without else) > Off-topic: how can I enable this compiler hint? Erm, I was referring to the

Re: [fpc-devel] Dangerous optimization in CASE..OF

Am 16.07.2017 um 21:08 schrieb Ondrej Pokorny: > On 16.07.2017 20:42, Florian Klämpfl wrote: >> "Ungültiger Maschinenbefehl (Speicherabzug geschrieben)" = Invalid >> opcode (memory dump written). >> Why? Because it does not range check before entering the jump table. > > OK, I confess I am not a

Re: [fpc-devel] Dangerous optimization in CASE..OF

On 16.07.2017 20:42, Florian Klämpfl wrote: "Ungültiger Maschinenbefehl (Speicherabzug geschrieben)" = Invalid opcode (memory dump written). Why? Because it does not range check before entering the jump table. OK, I confess I am not a C guy (I hated it in the university even more than

Re: [fpc-devel] Dangerous optimization in CASE..OF

On Sun, 16 Jul 2017 10:34:18 -0400 DaWorm wrote: > If the programmer builds a case statement on an enum, that includes all of > the possible enum values, and also includes an else clause, to me it seems > the programmer is implicitly telling the compiler that there is the >

Re: [fpc-devel] Dangerous optimization in CASE..OF

Am 16.07.2017 um 20:25 schrieb Ondrej Pokorny: > For now, Pascal enumerated types work as aliases for underlying ordinal > values - a concept that is > exactly the same as C enums: > Very good point: florian@ubuntu64:~$ cat test.cc #include enum tenum { e1,e2,e3,e4,e5,e6,e7,e8 }; int f(tenum

Re: [fpc-devel] Dangerous optimization in CASE..OF

On 16.07.2017 11:07, Michael Van Canneyt wrote: You are missing the point of an enumerated. The whole point of using an enumerated is that range checking *is not necessary*, because the values are 'by definition' correct. If the compiler cannot assume this, you're just using an integer with

Re: [fpc-devel] Dangerous optimization in CASE..OF

On 16.07.2017 19:24, Martok wrote: The good thing about case statements is that they tell me of every other programmer error: missing elements (if used without else) Off-topic: how can I enable this compiler hint? When compiling: program Project1; type TEnum = (one, two); var A: TEnum;

Re: [fpc-devel] Dangerous optimization in CASE..OF

Am 16.07.2017 um 16:34 schrieb DaWorm: > Does the compiler optimize away the else clause in this case? Seems to me it > should not. At least that isn't the behavior I would expect as a user. At least it should not do that without telling me. The good thing about case statements is that they tell

Re: [fpc-devel] Dangerous optimization in CASE..OF

> And you also have subranges of enum types. Can any assumptions made > about those in your opinion? > Does that mean that you would consider the same transformation of a > case-statement when using a subrange type as correct? And that putting a > value outside the range of a subrange into such

Re: [fpc-devel] Dangerous optimization in CASE..OF

On 16/07/17 09:12, Ondrej Pokorny wrote: On the one hand you say that the compiler can generate invalid values and on the other hand you say that the compiler can assume the enum holds only valid values. It can assume this because a program's behaviour is only defined if you initialise your

Re: [fpc-devel] Dangerous optimization in CASE..OF

On 15/07/17 21:34, Martok wrote: This will never generate a range check error, because the type information states that a tsubenum2 value is always a valid tsubenum value. Array indexing a special case of this, as semantically the expression you use to index the array is first assigned to the

Re: [fpc-devel] Dangerous optimization in CASE..OF

On Sun, 16 Jul 2017, Ondrej Pokorny wrote: On 15.07.2017 21:39, Jonas Maebe wrote: On 15/07/17 21:33, laza...@kluug.net wrote: Am Sa., Jul. 15, 2017 21:07 schrieb Jonas Maebe : I have said from the start that it is possible to store invalid values in variables

Re: [fpc-devel] Dangerous optimization in CASE..OF

On 15.07.2017 21:39, Jonas Maebe wrote: On 15/07/17 21:33, laza...@kluug.net wrote: Am Sa., Jul. 15, 2017 21:07 schrieb Jonas Maebe : I have said from the start that it is possible to store invalid values in variables through the use of a.o. pointers (which is

Re: [fpc-devel] Dangerous optimization in CASE..OF

On 15/07/17 21:33, laza...@kluug.net wrote: Am Sa., Jul. 15, 2017 21:07 schrieb Jonas Maebe : I have said from the start that it is possible to store invalid values in variables through the use of a.o. pointers (which is what the class zeroing does), explicit

Re: [fpc-devel] Dangerous optimization in CASE..OF

> This will never generate a range check error, because the type > information states that a tsubenum2 value is always a valid tsubenum > value. Array indexing a special case of this, as semantically the > expression you use to index the array is first assigned to the range > type of the

Re: [fpc-devel] Dangerous optimization in CASE..OF

Am Sa., Jul. 15, 2017 21:07 schrieb Jonas Maebe : On 15/07/17 20:52, laza...@kluug.net (mailto:laza...@kluug.net) wrote: On one hand, you try to be very fundamental about enums - you say that only declared enum values are valid. And there is no zero value for TMyEnum. TMyEnum is declared as

Re: [fpc-devel] Dangerous optimization in CASE..OF

Am 15.07.2017 um 17:17 schrieb Martok: > Several different ways of writing the (apparent) tautology "is EnumVar in > Low(EnumType)..High(EnumType)" all handle out-of-range-values (expressly, not > as > a side effect of something else). ... only because nobody implemented such an optimization

Re: [fpc-devel] Dangerous optimization in CASE..OF

On 15/07/17 20:52, laza...@kluug.net wrote: On one hand, you try to be very fundamental about enums - you say that only declared enum values are valid. And there is no zero value for TMyEnum. TMyEnum is declared as follows: TMyEnum = (one = 1, two); TMyEnum is not a number so it cannot be

Re: [fpc-devel] Dangerous optimization in CASE..OF

Am Sa., Jul. 15, 2017 12:45 schrieb Jonas Maebe : Classes are explicitly documented to initialise their contents with zero Excuse me, but you have a collision in the way you think :) On one hand, you try to be very fundamental about enums - you say that only declared enum values are valid. And

Re: [fpc-devel] Dangerous optimization in CASE..OF

On 15/07/17 17:17, Martok wrote: For example, if I index an array, I know bad things may happen if I don't check the index beforehand, so I must always do that. No, you don't always have to do that. That is the whole point of a type system. That if the compiler makes up the array access

Re: [fpc-devel] Dangerous optimization in CASE..OF

Am 15.07.2017 um 12:40 schrieb Jonas Maebe: > On 14/07/17 02:40, Martok wrote: >> There is a fundamental difference in the type system between a somewhat >> sensible (if unexpected) assumption in FPC and a more practical documented >> definition in every other Pascal compiler. An assumption that

Re: [fpc-devel] Dangerous optimization in CASE..OF

On 14/07/17 20:21, Ondrej Pokorny wrote: In this case, please fix the compiler so that it doesn't generate invalid values by default: program Project1; {$mode objfpc}{$H+} type TMyEnum = (one = 1, two); TMyClass = class public Enum: TMyEnum; end; Classes are explicitly

Re: [fpc-devel] Dangerous optimization in CASE..OF

On 14/07/17 02:40, Martok wrote: There is a fundamental difference in the type system between a somewhat sensible (if unexpected) assumption in FPC and a more practical documented definition in every other Pascal compiler. An assumption that even FPC follows only in this one single spot.

Re: [fpc-devel] Dangerous optimization in CASE..OF

On 14/07/17 20:46, Ondrej Pokorny wrote: > Btw, when compiling this program with default Lazarus Release build mode: > [snip] > I get a warning: > > Compile Project, Mode: Release, Target: project1.exe: Success, Warnings: 1 > project1.lpr(9,1) Warning: function result variable of a managed type

Re: [fpc-devel] Dangerous optimization in CASE..OF

Btw, when compiling this program with default Lazarus Release build mode: program Project1; {$mode objfpc}{$H+} type TMyEnum = (zero); function MyFunc(const aEnum: TMyEnum): string; begin case aEnum of zero: Result := '0'; end; end; begin WriteLn(MyFunc(zero)); end. I get a

Re: [fpc-devel] Dangerous optimization in CASE..OF

On 02.07.2017 22:02, Florian Klämpfl wrote: Am 02.07.2017 um 21:40 schrieb Martok: Honestly, I still don't understand why we're even having this discussion. Because it is a fundamental question: if there is any defined behavior possible if a variable contains an invalid value. I consider a

Re: [fpc-devel] Dangerous optimization in CASE..OF

Am 14.07.2017 um 10:04 schrieb Marco van de Voort: > In our previous episode, Martok said: >> There is a fundamental difference in the type system between a somewhat >> sensible >> (if unexpected) assumption in FPC and a more practical documented definition >> in >> every other Pascal compiler.

Re: [fpc-devel] Dangerous optimization in CASE..OF

In our previous episode, Martok said: > There is a fundamental difference in the type system between a somewhat > sensible > (if unexpected) assumption in FPC and a more practical documented definition > in > every other Pascal compiler. An assumption that even FPC follows only in this > one

Re: [fpc-devel] Dangerous optimization in CASE..OF

Am 13.07.2017 um 22:24 schrieb Marco van de Voort: > Personally I think the input validation angle to justify checking enums is > dragged-by-the-hairs. I completely agree with you on that. Although in a different way ;-) That was just the easily-observable breakage of a common pattern. If

Re: [fpc-devel] Dangerous optimization in CASE..OF

In our previous episode, Martok said: > Regardless of whether there may be some argument for this language change, I'm > still a firm believer in "don't surprise the user". There is literally no > precedent that this simplification has ever been done in any Pascal compiler > (quite the contrary),

Re: [fpc-devel] Dangerous optimization in CASE..OF

Hi all, any new ideas on this issue? I've been thinking about this a lot, and I do see where you're coming from. There is some theoretical advantage in treating enums like that. Only one minor issue: a language with that interpretation does not appear to be Pascal... You can find some results

Re: [fpc-devel] Dangerous optimization in CASE..OF

Hi all, Am 02.07.2017 um 22:02 schrieb Florian Klämpfl: > Am 02.07.2017 um 21:40 schrieb Martok: >> Honestly, I still don't understand why we're even having this discussion. > Because it is a fundamental question: if there is any defined behavior > possible if a variable > contains an invalid

Re: [fpc-devel] Dangerous optimization in CASE..OF

Good morning! Am 02.07.2017 um 22:02 schrieb Florian Klämpfl: > Am 02.07.2017 um 21:40 schrieb Martok: >> Honestly, I still don't understand why we're even having this discussion. > > Because it is a fundamental question: if there is any defined behavior > possible if a variable > contains an

Re: [fpc-devel] Dangerous optimization in CASE..OF

On Sun, 2 Jul 2017, Tomas Hajny wrote: By using file of enum (or any data type), you are explicitly telling the compiler it is OK. There isn't much difference between telling the compiler that all values in certain file are of certain type and telling the compiler that the next value read

Re: [fpc-devel] Dangerous optimization in CASE..OF

I store record data in files with a checksum (usually a CRC). I block read them into an array buffer and verify the checksum. If it passes, I assign via typecast the array buffer to a variable of the record type. If I'm the only one reading and writing the files that is usually enough to handle

Re: [fpc-devel] Dangerous optimization in CASE..OF

In our previous episode, Florian Kl?mpfl said: [ Charset UTF-8 unsupported, converting... ] > Am 02.07.2017 um 21:40 schrieb Martok: > > Honestly, I still don't understand why we're even having this discussion. > > Because it is a fundamental question: if there is any defined behavior > possible

Re: [fpc-devel] Dangerous optimization in CASE..OF

On Sun, July 2, 2017 18:39, Michael Van Canneyt wrote: > On Sun, 2 Jul 2017, Tomas Hajny wrote: > >>> By declaring it as a File of Enum, you are telling the compiler that it >>> contains only valid enums. >> >> Noone can ever ensure, that a file doesn't get corrupted / tampered with >> on a

Re: [fpc-devel] Dangerous optimization in CASE..OF

Am 02.07.2017 um 21:40 schrieb Martok: > Honestly, I still don't understand why we're even having this discussion. Because it is a fundamental question: if there is any defined behavior possible if a variable contains an invalid value. I consider a value outside of the declared range as

Re: [fpc-devel] Dangerous optimization in CASE..OF

On Sun, July 2, 2017 19:15, Marco van de Voort wrote: > In our previous episode, Tomas Hajny said: >> > Worse, tying it to range check would then have heaps of redundant >> checking >> > everywhere, not just enums. >> >> True. That's why I believe that Read from a (typed) file should perform >>

Re: [fpc-devel] Dangerous optimization in CASE..OF

Am 02.07.2017 um 19:47 schrieb Florian Klämpfl: > Am 02.07.2017 um 19:29 schrieb Martok: >>type Percentile = 1..99; >>var I: Percentile; >>begin >> I:= 99; >> inc(I); // I is now 100 > > Forgot the mention: > Tried with $r+ :)? That case is also documented. RTE in {$R+},

Re: [fpc-devel] Dangerous optimization in CASE..OF

Am 02.07.2017 um 20:29 schrieb Ondrej Pokorny: > On 02.07.2017 20:23, Florian Klämpfl wrote: >> And the compiler writes no warning during compilation? > > It does indeed. But about something else. Can we please stop derailing from the main issue here? > If we get a convenient way to assign

Re: [fpc-devel] Dangerous optimization in CASE..OF

On 02.07.2017 20:23, Florian Klämpfl wrote: And the compiler writes no warning during compilation? It does indeed. On 02.07.2017 20:18, Florian Klämpfl wrote: Yes, undefined behavior. I think I got your point :) You are right, sorry for wasting your time. If we get a convenient way to

Re: [fpc-devel] Dangerous optimization in CASE..OF

Am 02.07.2017 um 19:55 schrieb Ondrej Pokorny: > On 02.07.2017 19:29, Martok wrote: >> - Case statements execute *precisely one* of their branches: the statements >> of >> the matching case label, or the else block otherwise > > To support your argument, the current Delphi documentation says

Re: [fpc-devel] Dangerous optimization in CASE..OF

Am 02.07.2017 um 20:12 schrieb Martok: >> They are: >> http://docwiki.embarcadero.com/Libraries/XE5/en/System.Boolean > That prototype is a recent invention, it wasn't there in older versions. Also *sigh* This is the case since pascal was iso standarized. > the text sounds quite different

Re: [fpc-devel] Dangerous optimization in CASE..OF

On 02.07.2017 19:39, Florian Klämpfl wrote: So this means: var b : boolean; begin b:=boolean(3); if b then writeln(true) else if not(b) then writeln(false) else writeln(ord(b)); end. writes 3 in delphi? IMO you picked up a Delphi compiler bug/undocumented

Re: [fpc-devel] Dangerous optimization in CASE..OF

> They are: > http://docwiki.embarcadero.com/Libraries/XE5/en/System.Boolean That prototype is a recent invention, it wasn't there in older versions. Also the text sounds quite different somewhere else: http://docwiki.embarcadero.com/RADStudio/XE5/en/Simple_Types#Boolean_Types > Yes. What I

Re: [fpc-devel] Dangerous optimization in CASE..OF

Am 02.07.2017 um 19:51 schrieb Martok: > Booleans are not enums in Delphi (not even ordinals), They are: http://docwiki.embarcadero.com/Libraries/XE5/en/System.Boolean > but their own little > thing. "if boolean_expr" is always a jz/jnz, no matter what. Yes. This is an optimization which is

Re: [fpc-devel] Dangerous optimization in CASE..OF

On 02.07.2017 19:29, Martok wrote: - Case statements execute*precisely one* of their branches: the statements of the matching case label, or the else block otherwise To support your argument, the current Delphi documentation says the same:

Re: [fpc-devel] Dangerous optimization in CASE..OF

Booleans are not enums in Delphi (not even ordinals), but their own little thing. "if boolean_expr" is always a jz/jnz, no matter what. They are defined as 0=FALSE and "everything else"=TRUE However: var b : boolean; begin b:=boolean(3); if b = True then writeln(true) else if b =

Re: [fpc-devel] Dangerous optimization in CASE..OF

Am 02.07.2017 um 19:29 schrieb Martok: >type Percentile = 1..99; >var I: Percentile; >begin > I:= 99; > inc(I); // I is now 100 Forgot the mention: Tried with $r+ :)? >So if this is a legal statement, Well, it is a matter of definition, if a statement causing a rte

Re: [fpc-devel] Dangerous optimization in CASE..OF

Am 02.07.2017 um 19:29 schrieb Martok: > Addendum to this: > >> This was also always my intuition that the else block is also triggered for >> invalid enum values (the docs even literally say that, "If none of the case >> constants match the expression value") - and it *is* true in Delphi. >

Re: [fpc-devel] Dangerous optimization in CASE..OF

Addendum to this: > This was also always my intuition that the else block is also triggered for > invalid enum values (the docs even literally say that, "If none of the case > constants match the expression value") - and it *is* true in Delphi. There is a reason why this is true in Delphi:

Re: [fpc-devel] Dangerous optimization in CASE..OF

In our previous episode, Tomas Hajny said: > > Worse, tying it to range check would then have heaps of redundant checking > > everywhere, not just enums. > > True. That's why I believe that Read from a (typed) file should perform > such validation - but it doesn't at the moment, as mentioned in

Re: [fpc-devel] Dangerous optimization in CASE..OF

On 02.07.2017 18:49, Jonas Maebe wrote: No, there is no built-in checked conversion from integer to arbitrary enumeration types. That's why I suggested in the bug report that started this thread to file a feature request for such a conversion. Very good :) Are there any disadvantages of the

Re: [fpc-devel] Dangerous optimization in CASE..OF

On 02/07/17 18:43, Ondrej Pokorny wrote: Thanks, so there is no enumeration range checking from the compiler at all :/ Yes, there is range checking for enums. No, there is no built-in checked conversion from integer to arbitrary enumeration types. That's why I suggested in the bug report

Re: [fpc-devel] Dangerous optimization in CASE..OF

On 02.07.2017 18:28, Jonas Maebe wrote: On 02/07/17 18:26, Ondrej Pokorny wrote: Allow me a stupid question: how to convert an integer to enum with range checking? The current possibilities and possibly improvements have been mentioned elsewhere in this thread already *

Re: [fpc-devel] Dangerous optimization in CASE..OF

On Sun, 2 Jul 2017, Tomas Hajny wrote: By declaring it as a File of Enum, you are telling the compiler that it contains only valid enums. Noone can ever ensure, that a file doesn't get corrupted / tampered with on a storage medium. No-one can ensure a memory location cannot get corrupted

Re: [fpc-devel] Dangerous optimization in CASE..OF

On 02/07/17 18:26, Ondrej Pokorny wrote: On 02.07.2017 18:20, Jonas Maebe wrote: Range checking code is generated for operations involving enums if, according to the type system, the enum can be out of range. Just like with integer sub-range types. Allow me a stupid question: how to convert

Re: [fpc-devel] Dangerous optimization in CASE..OF

On 02.07.2017 18:20, Jonas Maebe wrote: Range checking code is generated for operations involving enums if, according to the type system, the enum can be out of range. Just like with integer sub-range types. Allow me a stupid question: how to convert an integer to enum with range checking? A

  1   2   >