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

2018-04-14 Thread Thorsten Engler
epascal.org> On Behalf > Of Ozz Nixon > Sent: Saturday, 14 April 2018 23:16 > To: FPC developers' list <fpc-devel@lists.freepascal.org> > Subject: Re: [fpc-devel] *** GMX Spamverdacht *** Re: Dangerous > optimization in CASE..OF > > following the grammar, I would sugg

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

2018-04-14 Thread Ondrej Pokorny
On 14.04.2018 15:16, Ozz Nixon wrote: following the grammar, I would suggest “in” when trying to do what you want, not “is”. if a in 3..10 then begin You can overload the IN operator: https://www.freepascal.org/docs-html/ref/refse104.html#x213-23500015.6 According to Jonas, this could

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

2018-04-14 Thread Ozz Nixon
ists.freepascal.org> On Behalf >> Of Ozz Nixon >> Sent: Saturday, 14 April 2018 22:43 >> To: FPC developers' list <fpc-devel@lists.freepascal.org> >> Subject: Re: [fpc-devel] *** GMX Spamverdacht *** Re: Dangerous >> optimization in CASE..OF >> >&g

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

2018-04-14 Thread Thorsten Engler
reepascal.org> > Subject: Re: [fpc-devel] *** GMX Spamverdacht *** Re: Dangerous > optimization in CASE..OF > > I understand the thread, however, in one of the ISO standards for > Pascal, the keyword is, is defined for type not value. The example > I gave is the only wa

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

2018-04-14 Thread Ozz Nixon
gt; >> -Original Message- >> From: fpc-devel <fpc-devel-boun...@lists.freepascal.org> On Behalf >> Of Ozz Nixon >> Sent: Saturday, 14 April 2018 22:13 >> To: FPC developers' list <fpc-devel@lists.freepascal.org> >> Subject: *** GMX Sp

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

2018-04-14 Thread Thorsten Engler
org> > Subject: *** GMX Spamverdacht *** Re: [fpc-devel] Dangerous > optimization in CASE..OF > > I have to ask why? > > i is Int64 only, will always be int64 only, so all other > comparisons are always skipped. > > I could see this, inside a method with an untyp