Hacker News new | ask | show | jobs
by FpUser 2214 days ago
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).
3 comments

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.

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

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.

You can typecast integer to pointers in Pascal. It's not memory safe.
You know, I can always jump from that cliff. Still keep wondering why don't I do it.
Please take your projected inadequacies elsewhere.
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.

What's your business?

As senior engineer at a security conscious firm, who used to freelance by writing exploits for code written by developers with your attitude, I want to make sure we don't use your software.

Likewise
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.
Yep really safe, Google and Microsoft security centers can confirm that.
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.

Not 70% caused by memory corruption bugs, I guess said clients are not a security target.
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.

How much do you think it costs?
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.
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.
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.

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