No shitstorm from my part :-)
I am working with Pascal, C and other programming languages (PL/1 for
example) for more than 40 years now,
and I am thinking sometimes about what makes programming languages
secure or insecure - or: what are the
common reasons for runtime errors?
Some observation
See below ...
Am 19.02.2024 um 02:00 schrieb James Richters via fpc-pascal:
>And if you have set the precision, then the calculation will be
identical to the calculation when you use a variable of the same type
(if not, it's indeed a bug).
This is what I have been trying to point out.Math
Am 17.02.2024 um 20:18 schrieb Florian Klämpfl via fpc-pascal:
const Xconst : single = 1440.0;
var y1, y2 : real;
y1 := 33.0 / 1440.0;
y2 := 33.0 / Xconst;
the division in the first assignment (to y1) should be done at
maximum precision, that is,
both constants should be converted by the
Am 17.02.2024 um 16:38 schrieb Bernd Oppolzer:
IMO, a compiler switch that gives all FP constants the best available
precision would solve the problem -
BTW: WITHOUT forcing expressions where they appear to use this
precision, if the other parts of the expression
have lower precision.
In fac
Am 17.02.2024 um 14:38 schrieb Michael Van Canneyt via fpc-pascal:
There can be discussion about the rules that the compiler uses when it
chooses a type, but any given set of rules will always have
consequences that may or may not be desirable.
Possibly some compiler switches can be invented
Am 17.02.2024 um 02:12 schrieb Ern Aldo via fpc-pascal:
It is possible math is being done differently by the compiler than by
programs? For math-related source code, the compiler compiles the
instructions and writes them to the program file for execution at
runtime. For compile-time constant
Am 16.02.2024 um 15:57 schrieb James Richters via fpc-pascal:
So you are saying when constant propagation is on, an expression should have a
different result than with constant propagation off?
The result of math when using constants MUST be the same as the result of
identical math using var
Am 16.02.2024 um 08:32 schrieb Florian Klämpfl via fpc-pascal:
Am 16.02.2024 um 08:23 schrieb Ern Aldo via fpc-pascal
:
Compile-time math needs to be as correct as possible. RUN-time math can worry
about performance.
So you are saying when constant propagation is on, an expression should hav
My opinions about the solutions below ...
Am 13.02.2024 um 12:07 schrieb Thomas Kurz via fpc-pascal:
But, sorry, because we are talking about compile time math, performance
(nanoseconds) in this case doesn't count, IMO.
That's what i thought at first, too. But then I started thinking about
Am 13.02.2024 um 10:54 schrieb Michael Van Canneyt via fpc-pascal:
On Tue, 13 Feb 2024, James Richters via fpc-pascal wrote:
Sorry for the kind of duplicate post, I submitted it yesterday
morning and I
thought it failed, so I re-did it and tried again.. then after that the
original one showe
aebe via fpc-pascal
To: fpc-pascal@lists.freepascal.org
Sent: Sunday, February 11, 2024, 23:29:42
Subject: [fpc-pascal] Floating point question
On 11/02/2024 23:21, Bernd Oppolzer via fpc-pascal wrote:
and this would IMHO be the solution which is the easiest to document and
maybe to implement
and
Am 11.02.2024 um 17:31 schrieb Florian Klämpfl via fpc-pascal:
On 09.02.24 15:00, greim--- via fpc-pascal wrote:
Hi,
my test with Borland Pascal 7.0 running in dosemu2 running 80x87 code.
The compiler throws an error message for calculating HH and II with
explicit type conversion.
The results
I didn't follow all the discussions on this topic and all the details of
compiler options of FPC
and Delphi compatibility and so on, but I'd like to comment on this result:
program TESTDBL1 ;
Const
HH = 8427.02291667;
Var
AA : Integer;
BB : Byte;
CC : Single;
To simplify the problem further:
the addition of 12 /24.0 and the subtraction of 0.5 should be removed, IMO,
because both can be done with floats without loss of precision (0.5 can
be represented exactly in float).
So the problem can be reproduced IMO with this small Pascal program:
program T
Am 17.12.2023 um 16:36 schrieb Adriaan van Os via fpc-pascal:
As the otherwise-clause is not in ISO-7185 Pascal, it seems more
plausible that Borland invented the else-clause (without semicolon)
independently. All other Pascals I have looked at, use an
otherwise-clause (with an obligatory sem
Am 17.12.2023 um 06:12 schrieb Adriaan van Os via fpc-pascal:
Anyway, the innocent looking case-statement does have some interesting
aspects.
Indeed.
My Stanford compiler tries to be portable across platforms;
due to its IBM mainframe heritage even on platforms that have "strange"
charact
I wrote a comment on the original Microsoft dev blog (for a non-Pascal
community), maybe it's of interest here, too ...
In normal Pascal procedure calls, such a vector of stack frame addresses
is not needed. A standard Pascal runtime knows all the time about the
current stack frame address of
Am 12.12.2023 um 17:51 schrieb Marco van de Voort via fpc-pascal:
Op 12-12-2023 om 17:48 schreef Anthony Walter via fpc-pascal:
Do any of the compiler devs know if Pascal programs for the x86
instruction set are using ENTER and its second argument to the best
possible effect? I am curious.
FWIW, when I added similar functionality to my Stanford Pascal compiler,
I chose not to allow arithmetic
of pointers, but instead I added some functions:
PTRADD (p, i) - p is type ANYPTR, i is integer, result is of type ANYPTR
PTRDIFF (p1, p2) - two pointers, the result is integer
ANYPTR is a pr
Am 18.06.2023 um 03:04 schrieb Hairy Pixels via fpc-pascal:
On Jun 18, 2023, at 1:07 AM, tsie...@softcon.com wrote:
This is interesting, because it's the first time I've ever seen "break" as a
valid command in pascal, and I've been using pascal since the mid/late 80s. All kinds of
dialects
Am 04.04.2023 um 08:16 schrieb Jacob Kroon via fpc-pascal:
Thanks for the tip above.
I was able to write a couple of perl-scripts that are able to convert
my old Pascal sources to something that fpc can parse. Amongst other
things, the scripts inject the "public name"/"external name"
annotat
Hi,
I don't know if this can help you, but in the 1980s I worked with a
library called GKS (graphic kernel system)
which I used to build such graphics like the following example:
http://bernd-oppolzer.de/fdynsb.pdf
This programs that did this were written in Pascal at that time.
It still work
Am 25.09.2020 um 22:16 schrieb James Richters via fpc-pascal:
I think that’s a GREAT quote from Niklaus Wirth, and I agree with that
whole heartedly… programs should be readable by humans… otherwise do
all your programming in assembly language… the whole POINT of a hi
level language is to ma
23 matches
Mail list logo
