Re: Fwd: What to do to get new users

Hairy Pixels via fpc-pascal <[email protected]>
Newsgroups gmane.comp.compilers.free-pascal.general
Message-ID <CAGsUGtmNHeShAAJ5TFYPs5fkX3ckM85paj+NyzbfZ0s_iYvzXw@mail.gmail.com>
 On Oct 21, 2024 at 7:54:22 AM, Bernd Oppolzer via fpc-pascal <
[email protected]> 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

_______________________________________________
fpc-pascal maillist  -  [email protected]
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.