[thePunisher]

This blog is not an article but a rant full of half-truths and outright lies. The author doesn't realize that most C# developers have no knowledge of the history of both Pascal and C (I'm old enough to know) because they were born decades after these languages came into being.

The author also misses the point that C and C++ are systems programming languages (for developing operating systems, device drivers and low-level stuff such as compilers) and Pascal is an application programming language. C and C++ were pressed into service for developing application programming because many nerds thought it cool to have the fastest benchmark speed test result and ignored the fact that these languages are unsafe to use on a day-to-day basis. That's why C# and Java were invented.

[monocasa]

I don't think the distinction you're making about C and C++ being systems languages, and Pascal being an application language totally holds.

Pascal is a totally fine system s language. AEGIS (a from scratch Unix like) was written in Pascal and by all accounts was a great option at the time.

And what makes C and C++ unsafe exists in Pascal.

[thePunisher]

Pascal was originally an application programming language, not a systems programming language.

These days you can probably mix assembly within your Pascal code or access pointers directly with some custom language extensions, but these weren't part of the original Pascal specification.

[monocasa]

You've absolutely always been able to interop with asm as well as access and set arbitrary pointers with Pascal.

I'm not sure where you got this idea that Pascal is memory safe.

[thePunisher]

Like I said, those were extensions made by compiler vendors, and not part of the original language.

Borland enabled adding Assembler to almost every language for which they made a compiler.

[monocasa]

You know that UCSD Pascal or ISO Pascal isn't the original Pascal, right?

[thePunisher]

The only takeaway for me is that most developers these days don't understand the difference between systems programming languages and general purpose application languages either.

We need an AOT compiled general purpose application language like C# with managed memory access. If people want to fool around with low-level stuff let them use Rust, assembler or C/C++.

[FpUser]

Modern C++ is actually pretty safe. Pascal is reasonably safe as well if you know what you're doing. And all this safety talk is over-hyped anyways. Just learn hot to program properly. I do not really remember when was the last time I had problem with "safety" in either Delphi or C++. My commercial apps (C++, Delphi and C for firmware run for years without a single crash report).

[thePunisher]

C++ is safe if you know how to use it properly, but this does incur overhead and many people aren't willing to incur any overhead because they want the fastest raw speed available. So they usually mess around with C like constructs in their C++ programs.

Pascal OTOH is 100% safe no matter what you do because you can't access pointers directly or do pointer math or out-of-bounds array access. The pointers available in Pascal are "managed" pointers which prevent you from accessing the underlying machine hardware.

This all incurs a little overhead, but you won't find any insecure Pascal programs due to memory mismanagement.

[FpUser]

>Pascal OTOH is 100% safe no matter what you do because you can't access pointers directly or do pointer math or out-of-bounds array access.

Maybe in your old classic pascal. Not true for modern Delphi/FreePascal incarnations of it. You can do pretty much anything including pointer math, including safe version of it.

[perl4ever]

I started out writing programs for the Mac in Pascal and believe me you, it was possible to crash the machine.

I think people get hung up on the theoretical capabilities of "pure" Pascal but the forms that people actually used had all sorts of extensions. Back in the day, whether you were using Pascal or C or whatever, it probably wasn't very standards-compliant anyway.

[apta]

https://www.zdnet.com/article/chrome-70-of-all-security-bugs...

[monocasa]

You can typecast integer to pointers in Pascal. It's not memory safe.

[FpUser]

You know, I can always jump from that cliff. Still keep wondering why don't I do it.

[monocasa]

Please take your projected inadequacies elsewhere.

[pjmlp]

Yep really safe, Google and Microsoft security centers can confirm that.

[FpUser]

Security centers can also confirm that any other language / software / system has holes.

I am not Microsoft/Google/etc and do not give flying hoot about their language preferences. I ran my own business and my clients are happy. As already said not a single complaint.

[pjmlp]

Not 70% caused by memory corruption bugs, I guess said clients are not a security target.

[FpUser]

My servers use proprietary protocols and one of the first thing my protocol handlers do is check validity of the input. You will not find generic "read until EOL/Whatever" in my code. The low level logic knows exactly what to expect at each point and how to validate it. All over encrypted connection.

Good luck hiring dedicated expert or team willing to break it. I am not Google and cost of trying to break my software where it matters far exceeds any potential benefits.

So sure, I am not the a prime choice as security target which makes it even better.

[thijsvandien]

While unsafe memory access can have consequences for stability, it has much broader implications than that. A system can keep running reliably while being heavily exploited.

[FpUser]

I am really tired of this FUD. Any system can be like this. You can have perfectly memory safe language and still be compromised. If you have enough dosh you hire experts and have them try to poke holes in your systems or analyze whether those have been compromised already. Until then all this security talk is not worth much.

[thePunisher]

But those would be logic errors, not memory management errors. If someone is stupid enough to pass user input directly to a shell or database then yes, they will get compromised.

But these comprise only 30% of all security errors as the research shows. Most are due to memory management issues.

[thijsvandien]

I don't see how it's FUD. Yes, any system can have security problems, but some are more likely to than others. "Just try harder" is no solution. With equal effort, better (suitable) tools still give better results.

[FpUser]

Let's just disagree. I think your definition of "better" is vastly different from mine. I also think that a mess most use as a current web development stack using "safe languages" poses way more danger security wise then my proprietary client/servers ever will.

[29athrowaway]

Java and C#, in that order.

C# appeared after Sun sued Microsoft for trying to embrace/extend Java.

[sedatk]

That strategy worked really well for Sun Microsystems.

[29athrowaway]

Some of the technologies associated with Sun that you can use today free of charge: NFS, ZFS, DTrace, Java, NetBeans, VirtualBox, OpenOffice, MySQL.

They don't deserve the trash talk.

[pjmlp]

Google helped a bit.

[pjmlp]

Apple used Object Pascal to write their OSes until they bought NeXT.