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

2017-07-02 Thread Jonas Maebe
On 02/07/17 11:59, Yury Sidorov wrote: Indeed, I've done some tests and found out that when range checking is enabled enums are not checked at all. Even array access with enum index is not checked. According to docs enums should be range checked:

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

2017-07-02 Thread Tomas Hajny
On Sun, July 2, 2017 17:05, Michael Van Canneyt wrote: > On Sun, 2 Jul 2017, Tomas Hajny wrote: > >> On Sun, July 2, 2017 16:48, Marco van de Voort wrote: >>> In our previous episode, Martok said: It is really hard to write code that interacts with the outside world without having a

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

2017-07-02 Thread Michael Van Canneyt
On Sun, 2 Jul 2017, Tomas Hajny wrote: On Sun, July 2, 2017 16:48, Marco van de Voort wrote: In our previous episode, Martok said: It is really hard to write code that interacts with the outside world without having a validation problem. Then you arguing wrong. Then you don't need

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

2017-07-02 Thread Tomas Hajny
On Sun, July 2, 2017 16:48, Marco van de Voort wrote: > In our previous episode, Martok said: >> It is really hard to write code that interacts with the outside world >> without >> having a validation problem. > > Then you arguing wrong. Then you don't need validation everywhere, but > something

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

2017-07-02 Thread Michael Van Canneyt
On Sun, 2 Jul 2017, Martok wrote: Hi all, The only way to get data with an invalid value in an enum in Pascal is by using an unchecked (aka explicit) typecast, by executing code without range checking (assigning an enum from a larger parent enum type into a smaller sub-enum type), or by

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

2017-07-02 Thread Michael Van Canneyt
On Sun, 2 Jul 2017, Florian Klämpfl wrote: So, we have a problem here: either the type system is broken because we can put stuff in a type without being able to check if it actually belongs there, or Tcgcasenode is broken because it (and _only_ it, as far as I can see) wants to be clever by

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

2017-07-02 Thread Mark Morgan Lloyd
On 01/07/17 22:45, Martok wrote: This is fine if (and only if) we can be absolutely sure that theEXPRESSIONRESULT always is between [low(ENUM)..high(ENUM)] - otherwise %eax inthe example above may be anywhere up to high(basetype)'th element of thejumptable, loading an address from anything

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

2017-07-02 Thread Florian Klämpfl
Am 02.07.2017 um 00:26 schrieb Martok: > Depending on the number of case labels, tcgcasenode.pass_generate_code > (ncgset.pas:1070) may choose one of 3 strategies for the "matching" task: > jumptable, jmptree or linearlist. Jmptree and linearlist are basically "lots > of > if/else", while

<    1   2