Re: [fpc-pascal] Docs: portability differences between Borland/FPC

2018-08-19 Thread Martok
Am 19.08.2018 um 14:55 schrieb Florian Klämpfl: > Please note again: in general, there are no defined rules for FPC as soon as > range check errors would occur. For FPC, > you are just documenting random *behavior* which might change even with the > next minor release. I know. And I have given

Re: [fpc-pascal] Docs: portability differences between Borland/FPC

2018-08-19 Thread Marco van de Voort
In our previous episode, Martok said: > Am 18.08.2018 um 23:25 schrieb Marco van de Voort: > > Summary: behaviour with range checks off is implementation defined? > No. "implementation different", but not really "implementation defined". > TP and Delphi are fully defined without range checks. In

Re: [fpc-pascal] Docs: portability differences between Borland/FPC

2018-08-19 Thread Florian Klämpfl
Am 19.08.2018 um 15:08 schrieb Martok: But I don't actually want to debate that here, just collect information for users. Well, you have to as you give people the wrong impression that they can control what happens if they suppress/ignore run time errors.

Re: [fpc-pascal] Docs: portability differences between Borland/FPC

2018-08-19 Thread Martok
Am 18.08.2018 um 23:25 schrieb Marco van de Voort: > Summary: behaviour with range checks off is implementation defined? No. "implementation different", but not really "implementation defined". TP and Delphi are fully defined without range checks. In fact, TP is defined as *having no runtime

Re: [fpc-pascal] Docs: portability differences between Borland/FPC

2018-08-19 Thread Florian Klämpfl
Am 19.08.2018 um 14:44 schrieb Martok: as soon as [something changes], Delphi shows exactly the same behavior as FPC. But that's kind of the point of this collection: sometimes the rules intersect, but for most cases, they don't. Please note again: in general, there are no defined rules for

Re: [fpc-pascal] Docs: portability differences between Borland/FPC

2018-08-19 Thread Martok
Am 19.08.2018 um 10:08 schrieb Florian Klämpfl: > Not really, you have also to fix the comments below because as soon as the > range is 0..127 and the test is against 127, > Delphi shows exactly the same behavior as FPC. Not really. You don't have to change the range, there is a warning emitted

Re: [fpc-pascal] Auto vars (again)

2018-08-19 Thread Jonas Maebe
On 18/08/18 23:18, Maciej Izak wrote: on SCOPEDINTERFACEDESTROY)... FPC core team said that this behavior of Delphi is not documented and not COM compatible (or is undefined in COM - I don't remember). Also there is some mystery example for large methods when Delphi is able to break the rule

Re: [fpc-pascal] why can't we define class operator for old fashion object type, but ok for 'advanced record' type?

2018-08-19 Thread Sven Barth via fpc-pascal
Ryan Joseph schrieb am Sa., 18. Aug. 2018, 19:38: > > > > On Aug 17, 2018, at 7:19 PM, Sven Barth via fpc-pascal < > fpc-pascal@lists.freepascal.org> wrote: > > > > However for classes there is the problem of temporary variables. Take a > := b + c + d. That is essentially compiled as t := b + c;

Re: [fpc-pascal] Docs: portability differences between Borland/FPC

2018-08-19 Thread Florian Klämpfl
Am 19.08.2018 um 01:49 schrieb Martok: Am 18.08.2018 um 23:39 schrieb Florian Klämpfl: This is plainly wrong, at least for the older delphis, the host type in delphi will be Byte (or even Shortint). It is actually shortint ... Correct, I was thinking of the default PackEnum. Which of course

Re: [fpc-pascal] Auto vars (again)

2018-08-19 Thread Maciej Izak
2018-08-18 20:26 GMT+02:00 Marcos Douglas B. Santos : > On Sat, Aug 18, 2018 at 2:04 PM, Ryan Joseph > wrote: > > > > How does TAutoFree in mORMot work? Never heard of this. > > See http://blog.synopse.info/post/2014/11/14/Automatic- > TSQLRecord-memory-handling worth to note that in FPC you