Object Pascal, Memory Safety, the US Whitehouse and future programming

[paule32]

Yes, I come from Germany.

I don't like War's, and Rassist's.
I don't against GBTT...
I don't like Discussion's about the ALONE EXISTENCE of the True, and only One God.
I don't like Flame War's.
I don't like Storking.

But:
I like Discussion's with Peoples around the World - each of Us have other Skills, and Advantages.
I know, that the Government's monitor Phone Call's, and Internet Activities.

You are not Alone
You can't believe, that when you use VPN or Proxies, you will be un-discovered
You can't believe, that when you speak against abroud People's, and then you would resume this by Statement's into the Public Domain if you are an VIP.

VIP's have a Task: They should be like a good Mood - they are Super when they a social.
I don't like VIP's that would appear in luxor, and swim in Money - on the Ground of the Workers, and lesser known Peoples.

I hate strikes about nothing.

I would have my Freedom, not Storking, and Silence - You know:
Let life, to life.

[JuhaManninen]

Generally speaking I agree with that but, every class is a _pointer_ and it is far from uncommon to read about problems programmers have with the freeing of classes.

The compiler implements it with a pointer but the concept is different. It is a reference. You cannot do pointer arithmetic which makes things much safer.
Yes, one must remember to free class references but there are good tools to spot leaks.

[domasz]

I would have my Freedom, not Storking, and Silence - You know:
Let life, to life.

Agreed!
Also I don't have anything against Germans you just write like a German- you capitalize nouns.

Yes, one must remember to free class references but there are good tools to spot leaks.

Back in the uni I had a teacher who said- always finish things after you start them. So when you write begin you press enter and write end; Then you move back and fill the block. Same thing - if you create an object, right after you free it and then between these 2 lines you can add more text.
I like this rule.

[vfclists]

And PHP is slightly better designed than Python, but no sane person tries to create serious software in it^*.
<snip>

3) When people write in PHP they just use built-in PHP functions and libraries written in PHP. This means pretty every PHP website, script, library works under any operating system. In Python people use extensions written in C/C++ that often are not available for other OS or need to be compiled with a C/C++ compiler. So to use Python you need another language compiler and often some knowledge how to use it.
4) Because of the above if you have a problem (eg. security problem) with a library in PHP you can easily fix it if you are a PHP programmer. If you are a Python programmer you won't fix anything because the problem is with C/C++ library and you would first need to learn that.
5) Python without its C/C++ libraries is useless while in pure PHP people have created lots of nice things

I beg to differ here. PHP depends on a lot of libraries developed in C and C++.

Sure more and more libraries are being written in pure PHP but some of those C/C++ libraries are going to be around for a while.

[440bx]

The compiler implements it with a pointer but the concept is different. It is a reference. You cannot do pointer arithmetic which makes things much safer.
Yes, one must remember to free class references but there are good tools to spot leaks.

Yes, classes are pointers that receive "special treatment" and that is also a problem.  For instance, normally when a procedure/function has a parameter that is "by value", that is, not "var" nor "out" then there cannot be side effects associated with that parameter (except if the parameter is a pointer to something), that is not the case when the parameter is a class (since the class is a pointer.)  Any changes to the class fields made in the function/procedure are persistent even though the class was passed by value.  Hiding the fact that the class is a pointer creates inconsistencies, being able to change fields in a persistent way is one of them.  If instead of a class what had been passed was a record (which in a way is similar to a class - it has fields) then the function/procedure would have received a copy of the record ensuring that changes are not persistent.

You're right that, at least pointer arithmetic is not allowed with classes but, that doesn't make them problem free.

[domasz]

I beg to differ here. PHP depends on a lot of libraries developed in C and C++.

Sure more and more libraries are being written in pure PHP but some of those C/C++ libraries are going to be around for a while.

There are libraries written in C/C++ but not very popular because:
1) still the most popular PHP hosting solutions are shared hostings where you can't install any libraries
2) a lot of people develop on Windows but most PHP servers run on Linux so you would need C/C++ libraries compiled for both
3) people got used to just use pure PHP libraries or execute command-line programs
Maybe you just work in a bit usual PHP environment and C/C++ are popular there.
Just to make sure- I am not talking about C/C++ libraries which are part of standard PHP installation (like mysql, curl, gd).

[Warfley]

Well, we know for a while now that the majority of security vulnerabilities are not caused by logic errors but by memory bugs. It's so bad that a real technique for sensitive applications (e.g. employed by browsers) to avoid use after free is to simply never call free on certain memory regions.

Cyber crime globally was estimated to have made 8.15 trillion USD in revenue, which is around twice the size of the GDP of Germany, the third largest economy in the world.

Like of course governments are worried about this, you must be insane to not be. The choice between a memory safe language and one that isn't is basically the choice if you like to triple the number of security vulnerabilities an attacker can exploit.

Also towards all the arguments that you can easily write memory safe code in unsafe languages, we know the stats, if that's so easily possible, why did this problem not have gotten better over the past 50 years?
Fact is people are fallable and the more possibilities there are to make mistakes the more mistakes will happen. We should design our tools to be as safe as possible, not expect everyone to just not make mistakes

[tr_escape]

Maybe we need more historical changes

https://www.governing.com/now/an-apology-to-cobol-old-technology-isnt-always-bad.html

[marcov]

Generally speaking I agree with that but, every class is a _pointer_ and it is far from uncommon to read about problems programmers have with the freeing of classes.

The compiler implements it with a pointer but the concept is different. It is a reference. You cannot do pointer arithmetic which makes things much safer.
Yes, one must remember to free class references but there are good tools to spot leaks.

You can call a method on arbitrary potentially stale references

[BeniBela]

Also towards all the arguments that you can easily write memory safe code in unsafe languages, we know the stats, if that's so easily possible, why did this problem not have gotten better over the past 50 years?

because people are not using Pascal!

[marcov]

Also towards all the arguments that you can easily write memory safe code in unsafe languages, we know the stats, if that's so easily possible, why did this problem not have gotten better over the past 50 years?

Note that from what I saw, those counted vulnerabilities are not classified by age, so many of them might be older than the period in say 2003 when security slowly became a major focus. (in all cases, managed or not)

[Warfley]

because people are not using Pascal!

Pascal has some great features for automated memory management. For example whenever performance is not required, I will use an array instead of a list or other container type, simply because the reference counting makes handling it much easier.

I also think managed records are probably the best addition to the language since generics, because they also allow creating very safe types.

[MMarie]

I personally want to add that (and keep in mind im no expert, so please do correct me if im wrong with anything; i'm a bit naive ):
Even though you could ensure memory safe programs in languages like C by your coding style, I think that they are more referencing the fact that next to no one uses such a coding style (and im not even sure that such a coding style will save you everytime from pitfalls like funky glibc or compiler behaviour, or what it would even look like).

Also, in my opinion, I would probably only classify languages such as Rust as "memory safe", because common pitfalls which lead to memory un-safety are prevented by the compiler almost all of the time (say if not using unsafe blocks, RefCells or similar; which you should avoid anyway). Pascal is relatively safe (compared to langs like C) but I wouldn't say its on the same level of memory safe as e.g. Rust.

[Warfley]

Also, in my opinion, I would probably only classify languages such as Rust as "memory safe", because common pitfalls which lead to memory un-safety are prevented by the compiler almost all of the time (say if not using unsafe blocks, RefCells or similar; which you should avoid anyway). Pascal is relatively safe (compared to langs like C) but I wouldn't say its on the same level of memory safe as e.g. Rust.

Pascal is defenitely not as safe as Rust or Garbage Collected languages like C# or Java. Especially due to the reliance on classes which require manual memory management, memory unsafe programming is still the main modus operandi for many programs. There are features that are memory safe, strings, arrays, COM interfaces and now newly managed records and anonymous functions, but unless you write a whole program from scratch with the sole goal of only using memory safe managed types (which requires not using the FCL or RTL as they rely on classes), this will only make a very small part of the program.

And I must also admit, even though I love Pascal, as I work in IT security, I would absolutely never recommend anyone use Pascal for anything that is not a low privilage single user application (mostly desktop application). Something like outward facing servers or command line tool used as part of automated scripts or build chains or so, are typical attack vectors where memory unsafe languages should not be used due to the security concerns

[marcov]

Something like outward facing servers or command line tool used as part of automated scripts or build chains or so, are typical attack vectors where memory unsafe languages should not be used due to the security concerns

Most server usage would be as plugin (ISAPI, apache module or the like) to a standard webserver, which obviously shields a bit.