<html><body><div class="gmail_quote">
<div dir="ltr" class="gmail_attr">On Oct 21, 2024 at 7:54:22 AM, Bernd Oppolzer via fpc-pascal <<a href="mailto:fpc-pascal@lists.freepascal.org">fpc-pascal@lists.freepascal.org</a>> wrote:<br></div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex" type="cite">
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></blockquote><div class="gmail_quote"><br></div><div class="gmail_quote" dir="ltr">FPC can take a pointer to stack memory. I don’t understand what the difference is with the ADDR function.</div><br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex" type="cite"><br>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></blockquote><div class="gmail_quote"><br></div><div class="gmail_quote"><div dir="ltr">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.</div><div dir="ltr"><br></div><div dir="ltr">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. </div></div><br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex" type="cite"><br>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></blockquote><br>
</div><div class="gmail_quote" dir="ltr">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.</div>
<br>
<div dir="ltr">
<br clear="all"><div><div class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr">Regards,</div> Ryan Joseph</div></div><br>
</div></body></html>