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

[monocasa]

Original Pascal was designed for bare metal systems programming on a CDC6000 series. Don't get snickety just because other people aren't abiding by your ahistorical definitions.

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

[FpUser]

I could not reply to your message one below so moving it here: >You're the one that has three times now commented on one of my posts trying to prove to yourself that everything you're doing is fine and there's nothing you could be doing better from a security perspective.

I am just expressing my opinion. You know, taking distraction from mundane work to talk technical things. I am not trying nor do I need to prove how I do my development/design and what tools do I use and frankly I do not give a flying hoot what others might think about it. I run my own business after all.

As to you particular point of language being unsafe because it allows typecast pointer to integer: allowing unsafe features in my view does not make language unsafe as long as it provides safe way of doing things as well. It is called flexibility in my book.

Security wise: could I've done better? Sure. Anything could be done better but you've probably heard about the law of diminishing returns. Does the fact that I use language that have unsafe feature automatically make my software unsafe if I do not use said features - big fat NO. Even if do use such feature (and rarely but sometimes I do for the sake of efficiency) it does not really change the main point.

[FpUser]

Likewise

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

[monocasa]

How much do you think it costs?

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