Sasa Zeman wrote: >> We don't consider this as a bug, it's for delphi compatibility reasons. >> These expressions are evaluated at compile time, so it's something >> differnt. If you want to get an error, compile with -Cr. > > The -Cr will point on error in the code, however, enabling range checking > will also affect on global speed performance.
The program won't compile with -Cr. > > Definition in documentation (RTL.pdf): > " > 29.20 EDivByZero > 29.20.1 Description > EDivByZero is used when the operating system or CPU signals a division by > zero error. > " > As defined, reported issue is a bug. As well globaly, in consistency terms. ... operating system or CPU ... but not the compiler ;) The point is: this div by zero is encountered at compilation time. The other option is to stop compilation always. Executing the operation at run time is useless imo and a waste of CPU cycles. > > Far I can see, the core of the problem is in definiton of Infinity constant > as 1.0/0.0 and NaN with ln(-1.0) or 0.0/0.0 No. These constants are defined in const blocks. A const block couldn't throw an exception. > Perhaps this is necessary to > avoid problem with probably difference between different CPU/FPUs. However, > IEEE specification should be followed by all of them and bits manipulation > to perform infinity should be enough, instead to calculate it (as is > performed currently). > > _______________________________________________ > fpc-pascal maillist - fpc-pascal@lists.freepascal.org > http://lists.freepascal.org/mailman/listinfo/fpc-pascal > _______________________________________________ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
