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 c

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

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 ele

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 little better and make t

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

phi bend a little this way than us their way. Alex On 04/21/2018 08:12 AM, Thorsten Engler wrote: -Original Message- From: fpc-devel 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

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

Thorsten Engler schrieb am Sa., 21. Apr. 2018, 14:12: > > -Original Message- > > From: fpc-devel On Behalf Of > > Martok > > Sent: Saturday, 21 April 2018 21:39 > > To: fpc-devel@lists.freepascal.org > > Subject: Re: [fpc-devel] Dangerous optimizati

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

> -Original Message- > From: fpc-devel 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 um 21:35 schrieb Ondrej Pokorny: > > Sve

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 b

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

On 13.04.2018 23:16, Sven Barth via fpc-devel wrote: Ondrej Pokorny mailto:laza...@kluug.net>> schrieb am Fr., 13. Apr. 2018, 21:16: On 13.04.2018 14:08, Sven Barth via fpc-devel wrote: Ondrej Pokorny mailto:laza...@kluug.net>> schrieb am Fr., 13. Apr. 2018, 12:52: I intro

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 tim

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 b

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

n >//... > If i is SmallInt then >//... > > (same with "as"). > > > >> -Original Message- >> From: fpc-devel On Behalf >> Of Ondrej Pokorny >> Sent: Saturday, 14 April 2018 19:03 >> To: fpc-devel@lists.freepascal.or

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

nt: 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? > > > > If 1 is TMyEnum then &g

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

How about following the same schema as with classes? If 1 is TMyEnum then //use hard cast here > -Original Message- > From: fpc-devel On Behalf > Of Ondrej Pokorny > Sent: Saturday, 14 April 2018 18:32 > To: fpc-devel@lists.freepascal.org > Subject: Re: [fp

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 e

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 intrinsi

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 exce

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 TryIntToEnum(c

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): Bool

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 an

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 >> https://bugs.freepascal.org/view.php?id=33603 >> > > What about enums with

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

On 13.04.2018 16:16, Martok wrote: 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 l

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

On 13.04.2018 14:08, Sven Barth via fpc-devel wrote: Ondrej Pokorny mailto:laza...@kluug.net>> 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 problem because Low() a

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 assi

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

Ondrej Pokorny schrieb am Fr., 13. Apr. 2018, 12:52: > 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

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 g

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 i

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 resurrecting

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 generates

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

>> And then there's bitpacked records... > > Indeed, and range checking. I mean, if you have the above declarations, > then what should be the behaviour in the following cases: Delphi generates no range checking code for enum assignments at all, only for mutation. All your examples work without er

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

I'll start at the end. >> There has to be a reason why everybody else chose Low-Level enums, except >> that >> it is far simpler to implement, right? > > I don't know, but I still don't understand why on Earth you would want > them in a strongly typed language. I see them as extremely useful as e

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 ther

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++ enu

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 Wri

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 >> WriteLn('SizeOf(TEnAr

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) = ', Low(

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 li

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 C

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 fortran

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 > possibility of illegal

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; b

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 a

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

Academically that may be true, but in the real world that code wouldn't be unreachable. I write code that deals with communication protocols all the time. I can't control what the other side sends. I have two choices. Write a lot of code to validate each and every element is within the proper ra

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

On 16/07/17 16:34, 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 possibility of illegal values stored in the

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

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 possibility of illegal values stored in the enum. Does the compiler optimize awa

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 v

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 ran

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 through the use of a.o

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 what the class zero

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 typecasts and assembly.

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 array.

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 follo

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 yet

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 ini

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 th

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 som

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 ev

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 doc

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. Severa

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 do

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 warni

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 valu

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. A

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 sing

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 anybody

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), a

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 of

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 val

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 in

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 d

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 storage

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

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

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+}, le

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 ordin

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 assi

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 the

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 somewhe

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 featur

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 wanted

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 in

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: http://docwiki.embarcadero.com/RADStudio/Tokyo/en/D

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 = Fals

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 2

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. > There

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: because

  1   2   >