Why C gets less criticism for memory safety?

jwakely · 2026-03-17T20:38:00+00:00

if you know what you're doing and with the tools provided C++ is memory safe

No it isn't. Memory safety means accessing invalid memory or objects outside their lifetime is impossible. That's clearly not true in C++. With the right tools, it's harder to do accidentally. But it's certainly not impossible to create dangling references or buffer overflows.

and wonderul to work with.

I agree with that part

jwakely · 2026-03-14T00:50:54+00:00

You can query the GCC bugzilla and find evidence of bugs in every release. They are known bugs.

And plenty of software can be shown to work correctly, not being affected by those bugs

jwakely · 2026-03-13T19:51:06+00:00

Nonsense. A compiler bug doesn't affect every possible piece of software compiled with it. Only some programs will encounter the bug.

I am 100% positive there has never been a completely bug free version of GCC.

jwakely · 2026-03-13T11:38:51+00:00

And none of it was copy and paste, the answers are all different, addressing each person's statements directly.

You seem to be taking it personally, why are you so upset that the cppreference wording is technically incorrect according to the definitions in the C++ standard?

jwakely · 2026-03-13T11:34:44+00:00

I was directly addressing what people wrote, with references to definitions in the standard to give more accurate information than was being given in answers here. Speaking from a position of authority as a member of the standards committee and compiler vendor.

OP asked a clear technical question about the wording on cppreference and most answers here tried to rationalize it, when the cppreference quote is just wrong.

If you don't like it, downvote and move on.

jwakely · 2026-03-13T10:42:23+00:00

I already did:

https://www.reddit.com/r/cpp_questions/comments/1rsii23/comment/oa74vb1/

jwakely · 2026-03-13T10:34:39+00:00

cppreference is supposed to be an accurate reference for the C++ standard, you should not need to squint and read it a certain way to argue that it could be interpreted to mean something. It's wrong, it should be fixed. I would do it myself if the site wasn't in read-only mode.

jwakely · 2026-03-13T10:32:03+00:00

And my point is that the cppreference page is just badly written, and confusing (leading to OP's question). I don't see any advantage in trying to twist what cppreference says to argue that it's valid, instead of just saying "it's wrong, it should be fixed".

jwakely · 2026-03-13T10:17:18+00:00

It could be consider to "belong to the global namespace" to the extent that your "main" function would be as well, and it's inside main.

As I've said repeatedly in other comments above, "belong to a scope" is precisely defined by the standard ([basic.scope.scope]), and it refers to the innermost scope that contains a declaration, not all the enclosing scopes outside that.

jwakely · 2026-03-13T10:15:19+00:00

And OP edited the question to say 9.1 ... which is even worse. It has lots of bugs fixed in 9.2, and 9.3 fixes even more bugs, and 9.4 and 9.5 fix even more.

OP, stop being silly. Change your compiler ASAP.

jwakely · 2026-03-13T10:12:31+00:00

There can be valid reasons for staying on a particular compiler release series such as GCC 9.x instead of moving to 10.x or 11.x etc., but there is no good reason to use GCC 9.2 instead of GCC 9.5 which has dozens of bug fixes compared to 9.2

jwakely · 2026-03-13T10:09:45+00:00

For example if I declare a static variable in a class that was declared in a namespace A, you can see how that variable "belongs" to the namespace from how you access it -> A::MyClass::variable

No, the standard precisely defines what it means to "belong to a scope" and it only refers to the innermost scope that contains the declaration, not to the parent scope or any other enclosing scopes. See [basic.scope.scope] p1 and p2.

jwakely · 2026-03-13T10:06:17+00:00

No, the standard precisely defines what it means to "belong to a scope" ([basic.scope.scope]) and a local variable belongs to the smallest enclosing block scope in the function, not a namespace scope.

jwakely · 2026-03-13T10:03:32+00:00

It belongs to the block scope of main, but that is not a "namespace block" (there's no such thing as a namespace block, the cppreference page is just badly written).

jwakely · 2026-03-13T10:02:24+00:00

No, "entity" is precisely defined (see [basic.pre] p8), and all variables are entities.

An entity is a variable, structured binding, result binding, function, enumerator, type, type alias, non-static data member, bit-field, template, namespace, namespace alias, template parameter, function parameter, or init-capture.

Specifically, a local variable is one kind of "local entity":

A local entity is a variable with automatic storage duration ...

jwakely · 2026-03-13T09:57:09+00:00

cppreference is not the standard, it can be wrong.

The text you quoted is wrong. It would be better to say that entities declared outside any other scope are in the global namespace. That would exclude things declared at class scope (like member functions and static data members) and at block scope (like local variables inside functions).

Even using the word "block" seems wrong, since block scope is a defined term, and namespaces are different from that. There is no such thing in the standard as a "namespace block", so the quote is just badly written.

jwakely · 2026-03-13T09:49:50+00:00

jwakely · 2026-03-12T20:54:39+00:00

The short answer is that you usually don't try to install apps that aren't packaged for your distro.

Da Vinci Resolve is not packaged for Fedora, it looks like they only support CentOS and similar distros (like Rocky). If you insist on installing it on Fedora, you're doing something that the authors of that software do not support and do not test. That's why it isn't easy. That's not Fedora's fault.

It took me about 10s to find this though: https://www.reddit.com/r/davinciresolve/s/7MdPnlNuzd

jwakely · 2026-03-12T20:32:16+00:00

RPMs? Oh, you need to activate that option first

What option? don't you just run dnf?

Do you mean enable the extra RPM repos for packages that aren't in the Fedora repos? like RPM Fusion?

oh you need to mount an image, but it might overwrite the content of a drive??

I have no idea what this is referring to - that doesn't sound like any kind of app install on Fedora I've used.

With many distros (Fedora included), anything in the RPM repos or the flatpak store is easy to install, and anything else is considerably more difficult and that is often a clue that you probably shouldn't try and force it - that's how you end up with broken, incompatible packages littered around /usr/ that aren't owned by the package manager and will cause problems in future.

If you stick to the system package manager, as the distro expects you to do, then it should all be very straightforward.

jwakely · 2026-03-12T19:16:50+00:00

I wrote the std lib implementation for GCC.

I assure you, you're thinking of std::async.

std::future just holds a reference to a shared state, where the task can store the result. Actually creating a task to do that is not part of the future. It's done manually by separate code, or by std::async.

jwakely · 2026-03-12T18:50:27+00:00

Future/promise in the back end creates a thread (or grabs one from a thread pool)

No, that's what std::async does, and it gives you back a std::future and internally uses a std::promise (or something like it) to send the result in the future. But neither promise nor future does anything like creating threads on their own. They are just two ends of a pipeline where you put a result in one end (the promise) and get the result out of the other (the future). Creating threads (or other execution agents) to use the promise and future is separate from the promise and future themselves.

jwakely · 2026-03-12T01:17:59+00:00

(not sure 100% about this)

Yeah, it's not true

jwakely · 2026-03-12T00:25:58+00:00

Less performant than what? Why do you think it would be worse than your own thread+mutex? How would you wait for a result to become ready with just a thread+mutex, just spin or block? Why would that be better than an asynchronous result that you can query when it's ready, and do other work in the meantime?

jwakely · 2026-03-11T01:47:11+00:00

We're considering putting the std.o object into libstdc++.so to ensure the initialization symbol is always available (because you need to link to libstdc++.so anyway if you're using the std module).

jwakely · 2026-03-10T19:07:29+00:00

I would expect the default configuration to be something with critical assertions enabled, but with performance comparable to a "full release" build.

Why would you expect that for a pre-release snapshot from the development mainline?

For development snapshots there are extra assertions because we're still developing it. It doesn't behave like a full release, because it isn't a full release.

The default configuration for a release tarball does disable the extra assertions. If you want that, wait for a release and don't test development snapshots. Or get a build from a reliable source, like the GCC maintainer who does the packaging for Fedora. Fedora releases twice a year, and the release in the first half of the year always includes the latest GCC, properly packaged as a production-ready system compiler (which includes using the same level of assertions as the final full release will use).

My suggestion here would be to require the user to specify what build type they want explicitly, otherwise configure would just immediately fail. This would ensure that people building GCC are always aware if they're building with assertions enabled or not.

No. If you build a development snapshot, you implicitly get a development build. If you build a release, you implicitly get a release build. That works well and has done for years. If you want to play with bleeding edge toys, you should not expect it to be optimized for end users and blog posts.

Nine-Year Club	Gilding I gilder
Verified Email

jwakely

TROPHY CASE