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