[fpc-pascal] Fwd: What to do to get new users

[Bernd Oppolzer]

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freepascal.org/pipermail/fpc-pascal/attachments/20241021/69107ce1/attachment-0001.htm>