Just a heads up about the NSA list of memory-safe programming languages

[madscijr]

Basically they're warning the public to stay away from C and C++ for security reasons. I know QB64PE ain't C, but because it uses a C compiler as part of its tool chain, people who use QB64PE at work at a bigger security-conscious company might find the IT department locking things down (like they always do!) so just a heads up! You might want to proactively contact your IT group and let them know why they might find minigw on your system, and provide them the info they need to allow you to keep it on your machine. The QB64PE devs might be able to tell us if QB64PE using minigw opens it up to the kinds of memory exploits that programming directly in C/C++ might, and if not, explain why, so anyone affected knows what to tell their IT dept. They've been limiting our tools and options forever, and each year it's more and more, thanks to those pesky hackers, and it's damn annoying! (But maybe better annoying than being the guy who gets blamed for the next big security breach, right?) Anyway I hope this helps!

The NSA list of memory-safe programming languages has been updated

[DSMan195276]

The MinGW usage of QB64PE is largely an implementation detail, the important questions are about the language itself and what it can or cannot do. Languages like Rust ultimately compile down to native code the same as we do and could produce native code with memory safety issues - it's the language design that allows the compiler and/or runtime to prevent memory-safety issues that ultimately makes them "memory-safe" languages.

For the QB64PE language, I would say it's mostly a memory-safe language, but definitely not entirely. It doesn't have pointers or references, so most of the typical issues aren't even possible, and Strings and arrays are bounds checked when you use them. The language however is not memory-safe if you make any use of `_MEM` - specifically either using `_MEM` with `$CHECKING:OFF`, or using the `_MEM(offset, len)` syntax.

Other usages of `_MEM` do get bounds checked to the region the `_MEM` is made for and should always be memory-safe, but I would personally not bet in there being no situations where you could screw it up or write over a pointer or something. For example, we allow you to do `_Mem(m)` where `m` is another `_Mem` type (that's probably a bug), doing that can allow you to break the bounds checking. Many languages on the list do allow you to break bounds checking intentionally, so that's not strictly a deal breaker, but it does make the situation a bit unclear.

From an implementation standpoint though, the QB64PE runtime is written in C++ (and really, not the best C++), and there's plenty of things in QB64PE that are buggy and will cause memory safety issues even if they shouldn't. Ex. This is a memory safety bug in the runtime that could be triggered by QB64PE code.

[madscijr]

The MinGW usage of QB64PE is largely an implementation detail, the important questions are about the language itself and what it can or cannot do.
...
Many languages on the list do allow you to break bounds checking intentionally, so that's not strictly a deal breaker, but it does make the situation a bit unclear.
...
there's plenty of things in QB64PE that are buggy and will cause memory safety issues even if they shouldn't. Ex. This is a memory safety bug in the runtime that could be triggered by QB64PE code.

That all makes sense and thanks for taking the time to explain - I just figured it should be addressed and wanted to open a conversation about it and the devs can decide what, if anything, needs addressing, or else provide advice. It sounds like QB64PE is not a big risk unless you get crazy with _mem or your program uses large strings in a way that triggers that qbs_data_size issue. I'll leave it to the folks who know about that stuff to clarify or work out. Thanks again!

[Pete]

List...

• Go
  
• Rust
  
• C#
  
• Swift
  
• Java
  
• Ruby
  
• Python
  
• Delphi/Object Pascal
  
• Ada
  

I went to the "Go" site, but it crashed. Probably a memory issue, but I'd bet they'd deny it.

Rust is okay, but it takes forever to iron out the bugs.

C# (pound) as if C and C++ isn't bad enough, now they want to pound it into us. No thanks.

Swift would be okay, but I'd have to buy a special permit to park my unicorn in front of the Delirium Store.

Java DO:LOOP until what can I say about JAVA that hasn't already been said.

Ruby or NOT Ruby. I tried it on Monday, but then it was goodbye Ruby Tuesday.

Python should come with the following warning: "Ye who enter abandon all hope."

Pascal: It was once stated that Pascal will be with us forever, but then someone discovered fire.

Ada: I tried to learn it once, but my A.D.D. prevented me from getting very far. Made one app for my Oriental friend, "Hello Wo"

- Pete

[DSMan195276]

The MinGW usage of QB64PE is largely an implementation detail, the important questions are about the language itself and what it can or cannot do.
...
Many languages on the list do allow you to break bounds checking intentionally, so that's not strictly a deal breaker, but it does make the situation a bit unclear.
...
there's plenty of things in QB64PE that are buggy and will cause memory safety issues even if they shouldn't. Ex. This is a memory safety bug in the runtime that could be triggered by QB64PE code.

That all makes sense and thanks for taking the time to explain - I just figured it should be addressed and wanted to open a conversation about it and the devs can decide what, if anything, needs addressing, or else provide advice. It sounds like QB64PE is not a big risk unless you get crazy with _mem or your program uses large strings in a way that triggers that qbs_data_size issue. I'll leave it to the folks who know about that stuff to clarify or work out. Thanks again!

On the `qbs_data_size` thing, I'd clarify that it's just a runtime bug, all languages have runtime bugs and some of them can cause memory safety issues, that's not specific to QB64PE. There's also definitely plenty more of them, some documented in GitHub and others undiscovered. QB64PE has more bugs in that category than most languages though, I'd say But it's ultimately not a language problem, the runtime could be fixed and then your program is memory-safe again (as opposed to a language like C, where the language allows things that the compiler or runtime could simply never check for correctness).

I think, in a general sense, the QB64PE language itself is memory-safe if there is no `_Mem` usage in your program. If there is `_Mem` usage, then it depends what exactly you do with it, the typical usages are bounds-checked and memory-safe.

[TerryRitchie]

The only languages I've personally tried in the list are Python, Pascal, and Ada.

Python is fun until it's not.

I put many years into Pascal programming back in the early 90's. It was a sad day when Borland dropped it. Turbo Pascal was blazing fast.

Ada is used mostly for government and military work. I took a few x86 Assembler college courses while I was in the Marine Corps and the instructor gave me a copy of Ada 83 (he was a Grumman rep that wrote code for military aircraft). It was a damn hard language to use but extremely memory safe even back then due to the compiler finding errors instead of relying on runtime errors. I lost interest after Ada 95 was introduced. It sort of resembled Pascal as I remember it.

I briefly looked at Ruby on Rails when I was deciding back in the mid 2000's if I wanted to continue coding web sites for some side-hustle cash. I decided against it because there was not a bit of joy in it whatsoever. Staring at anything HTML related for long hours on end will cause dain bramage.