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

[Hairy Pixels]

 On Oct 21, 2024 at 7:54:22 AM, Bernd Oppolzer via fpc-pascal <
fpc-pascal at lists.freepascal.org> wrote:

> 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.
>

FPC can take a pointer to stack memory. I don’t understand what the
difference is with the ADDR function.


> 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.
>

then isn’t Pascal’s requirement to predeclare uninitialized variables the
worst possible design? In C you can at least declare a variable with its
assignment in one step but with Pascal by design you can always read
uninitialized memory with the exception of arguments.

Many bugs I’ve caused because I didn’t set the “result” of a function for
example. I wish they could make that an option to always set the default
value.


> 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.
>

Why did the smart pointers and RAII help? FPC does nothing to help you
manage memory so I would expect more leaks. Being able to declare classes
on the stack and destroy automatically automates away a big category of
memory leaks right there.


Regards,
    Ryan Joseph
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freepascal.org/pipermail/fpc-pascal/attachments/20241020/3a73a9cb/attachment.htm>