<!DOCTYPE html>
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<p>No shitstorm from my part :-) <br>
</p>
<p>I am working with Pascal, C and other programming languages (PL/1
for example) for more than 40 years now, <br>
and I am thinking sometimes about what makes programming languages
secure or insecure - or: what are the <br>
common reasons for runtime errors? <br>
</p>
<p>Some observations: <br>
</p>
<p>1. a big problem IMO is the null-termination of C strings (or:
the possibility to use it or not use it, say: memcpy). <br>
This C paradigm often creates hard-to-find runtime errors;
languages, which operate on fixed-sized strings or <br>
strings with length fields like PL/1 varchars don't have this
problem and are more secure</p>
<p>2. Automatic checking of array bounds should always be enabled,
and I prefer languages that support this (like Pascal <br>
and PL/1, for example). For example: in the 1980s, I translated a
large Fortran program to Pascal, and I suddenly <br>
observed how many bounds checking errors still remained in the
Fortran program (although it was in production use<br>
for 4 years). <br>
</p>
<p>3. Standard Pascal has only pointers, which point to the heap and
are created by the NEW procedure. <br>
I am the maintainer of another Pascal dialect (Stanford Pascal) -
and, like many others, I have an ADDR function <br>
which allows to assign the address of a stack variable to a
pointer (and pointer arithmetic and so on). <br>
So this may look like pandora's box, but IMO this is needed to
write useful programs - and it needs to be done carefully, <br>
of course. Run time errors are created by using uninitialzed
pointers etc.; but that's not much different from using <br>
ANY OTHER variable without initialization. We have no protection
against this with current platforms. <br>
</p>
<p>4. This said, missing initializations are another major source
for runtime errors. I am working much on IBM mainframes. <br>
IMO, a big part of the "stability" of the mainframe platform comes
from the fact that on this platform <br>
many programs (written in COBOL and PL/1) work with DECIMAL data,
where uninitialized variables <br>
(with hex zeroes) are NOT VALID and create runtime errors, when
referenced. In constrast, with binary <br>
variables like integers, every bit pattern has a meaning, and you
never get a runtime error when <br>
referencing a variable which has not been initialized. With some
historic platforms like the Telefunken TR440 <br>
machine, you had the possibility to initialize the stack frames
with a bit pattern that always creates runtime <br>
exceptions when you referenced uninitialized data ... this was
possible because of the storage tags the <br>
Telefunken machine had. If you referenced uninitialized data (even
integer), the Telefunken machine <br>
produced a runtime error, called "Typenkennungs-Alarm".
Unfortunately, such concepts of the 1960s <br>
and 1970s didn't survive. <br>
</p>
<p>5. My observation regarding C++ versus C: we once added C++
components to a large C software package <br>
(insurance math). The C++ evangelists told us that we would get
more security (among other goodies). <br>
But what we observed after some months or years: in the C++ area
in almost every release we had<br>
hard to find memory leaks (the application requiring more and more
memory until hard stop). <br>
It took us advanced tools like ValGrind or special diagnostic
memory managers (from IBM)<br>
to diagnose and repair the C++ functions which were the culprits.
<br>
</p>
<p>My summary: <br>
</p>
<p>- Pascal - by language definition - is much better in this
respect than C or C++<br>
- Garbage collection doesn't really help and makes things slow
(counter example: in my Stanford Pascal, <br>
when working with strings, for example concatenation etc., this is
done in the string workarea, <br>
and the temporaries there are garbage collected at statement
boundaries ... this is necessary and <br>
cannot be avoided) <br>
- to write useful programs, you occasionally need pointers and
functions operating on them <br>
(using explicit lengths, maybe) and you have to take care, when
using such functions<br>
</p>
<p>HTH, kind regards</p>
<p>Bernd <br>
</p>
<p><br>
<br>
</p>
<div class="moz-cite-prefix">Am 19.10.2024 um 16:54 schrieb greim---
via fpc-pascal:<br>
</div>
<blockquote type="cite"
cite="mid:81090f0d8ef7eede9112359dc1c63f50@frontapp.com"><!--[if (gte mso 9)|(IE)]><style type="text/css">.main-style-8bf5fc97988d43a9251e { font-family: sans-serif; font-size: 11pt; /* inherit */ }</style><![endif]-->
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
<div style="/* inherit */" class="main-style-8bf5fc97988d43a9251e">
<div>Regarding Memory Management</div>
<div><br>
</div>
<div>Its possible to write a Pascal program w/o any pointer, but
it may be not elegant and interfaces to some C-like GUI
structures, as used in all common OSs, are impossible. <br>
</div>
<div><br>
</div>
<div>But, I am using Borland Pascal (sic!) and also FreePascal
(no Lazarus) for small embedded system for over 25 years now
w/o any pointer. <br>
</div>
<div>Code is sometimes ugly, but it is (proofed by reality with
many different projects) hard rock stable for 24/7/365
applications. <br>
</div>
<div>Maybe I am wrong, but afaik, procedural programming w/o
objects and pointers requires no add. memory management. <br>
</div>
<div>The size and memory location of all variables is fixed.
And, yes, of course, you have to care about an array access,
but $R+ is your friend. <br>
</div>
<div><br>
</div>
<div>See: N. Wirth Algorithms and Data Structures chapter 4.2: <br>
</div>
<div><i>"A further consequence of the explicitness of pointers
is that it is possible to define and manipulate cyclic</i></div>
<div><i>data structures. <b>This additional flexibility</b>
yields, of course, not only increased power but also
requires</i></div>
<div><i><b>increased care </b></i><i>("erhöhte Sorgfalt" in the
German ed.)</i><i><b> by the programmer</b>, because the
manipulation of cyclic data structures may easily lead to</i></div>
<div><i>nonterminating processes.</i></div>
<div><i><b>This phenomenon of power and flexibility being
intimately coupled with the danger of misuse</b> is well</i></div>
<div><i>known in programming, and it particularly recalls the
GOTO statement."</i></div>
<div><i><br>
</i></div>
<div>So as in real life: the price for freedom is increased
care!<br>
</div>
<div>I am awaiting your shitstorms......<i><br>
</i></div>
<div><i><br>
</i></div>
<div>Markus</div>
</div>
</blockquote>
</body>
</html>