> there are simple ways to avoid shooting yourself in the feet with those

A cursory look at the CVE list for any C software in the wild indicates that no, there are not simple ways to avoid shooting yourself in the feet with manual memory management in C. It's _incredibly hard_ even for "elite" programmers who have a lot of incentive to avoid these problems. The counterpoint is that people are probably going to spend less time looking for ways to maliciously use those problems in your C game than they are in the Linux kernel, but there is plenty of potential for even seasoned C coders to engage in bullet-on-foot violence.

Yeah, I am not talking about vulnerabilities. I am simply talking about ease of use and avoidance of leaks and crashes.

Writing super secure code is usually not a requirement for gamedev, and I completely agree, this is hard and potentially harder in C than, say, in Rust.

It's a requirement if you do network I/O whether you realize it or not.

In gamedev, we often use UDP for network I/O.

I am far from an expert in security but I've done a bit of reversing/hacking when I was 16 years old (DOS era)

I think this is hard to check for everything, but in my opinion, good security can be achieved with extreme simplicity.

Packets are fixed-size, every fields are manually bound checked and the packet is rejected if anything looks wrong.

That jibes with my knowledge.

But I've seen some real weird stuff before. ;) Folks using variable-length fields and happily just dumping the contents into eval(), all sorts of awful.

Bad code is bad code, in any language.

If a bug in a game's network IO crashes/takes over the whole OS, the security vulnerability is in the OS, not in the game.

No. Security is a full-stack endeavor. At all levels it is incumbent upon software professionals to build secure and resilient systems, any time they're exposed to a network. The OS should backstop your efforts, not replace them.

I disagree. As a user, I want to be able to run weird software without having it impact the rest of my system. Browsers and mobile OSs get this much more right than desktop OSs.

This does not meaningfully follow. What you "want" is orthogonal to the responsibility of the vendors of software.

The OS should protect where it can. So should software, lest your networked game nuke, say, the parts of your home directory to which it has permissions because without those permissions it can't do something it needs to.

This is just defense-in-depth. It's super basic stuff and HN is literally the only place I see people galaxy-braining about the idea that you have an obligation to not write shit code.

I suspect GP's point is that a networked game should be limited in access to only parts of one's home directory relevant for that game (that is: the game's own save data or configuration files or what have you). It is absolutely the job of the operating system to provide that sort of sandboxing/isolation.

Sure. That's great. That also breaks down sometimes, too.

Defense in depth. Write good, sane, secure, fail-closed code when you want to ship that code to other people--or don't write code.

That's not the point. The point is, if you do network I/O, you are processing untrusted packets from the internet. If a carefully crafted set of such packets can trigger, say, a buffer overflow, you're toast.

A first line of defence is authentication. Make sure the packets come from a trusted source (you can MAC each packet for this), so only those trusted sources could possibly trigger the vulnerability.

If the only trusted source is an authoritative server, you might be able to hide that buffer overflow. If your network code is peer to peer however, you have to trust the other players not to run a cheat that takes over your machine… but at least that's not the whole internet.

Vulnerabilities can be used to cause crashes.

In fact, generally a memory safety vulnerability will initially manifest itself as a crash before a more advanced targeted exploit can be used against it.

>Writing super secure code is usually not a requirement for gamedev

Many consoles have been "jailbroken" by making buggy games load specially crafted savegames that ended up in code execution.

That also extends to players downloading innocent-looking maps, savegames, models. etc that exploit bugs and end up in code execution too.

Also if you have an online game then you can have RCE bugs, especially if players are expected to be able to connect to 3rd party servers.

(Not saying I necessarily disagree with you, just a counterpoint)

> Many consoles have been "jailbroken" by making buggy games load specially crafted savegames that ended up in code execution.

That's an argument for using C in gamedev, isn't it? ;)

These are game developers though. On the list of requirements and priorities, I'm sure code safety is right beside commenting code and clean code. Not in a disparaging way. But tight deadlines, crazy expectations and insane work hours doesn't leave much time or energy to worry about it.

Not sure that's a good point. The CVE list for almost any programming language can get you to the conclusion that you can shoot yourself in the feet despite not being as tricky as C.

> A cursory look at the CVE list for any C software in the wild

How can I see that list? I'm interested in comparing languages this way.

Writing game engines in C++ without using any OOP features, makes perfect sense to me. Other than the author likes C, he failed to show me why his approach is better than yours. I found it very light on details.

Writing game engines in C++ without using destructors is just foolish.

If by OOP you mean virtual functions? Nobody uses that stuff much anymore, except Java refugees. (They use shared pointers, too.) But, anyplace you would use a function pointer in C, it's cleaner with a virtual function, and often faster.

> Writing game engines in C++ without using destructors is just foolish.

Why? My understanding is that in modern game dev you're mostly traversing large arenas of structured memory, and you avoid freeing individual objects like the plague.

Memory is just one kind of resources. Games do tons of I/O, often gigabytes/second. To illustrate, any PC game has a lot of places which call GPU driver like this:

    D3D11_MAPPED_SUBRESOURCE mapped;
    context->Map( buffer, 0, D3D11_MAP_WRITE_DISCARD, 0, &mapped );
    // Write memory address pointed by mapped.pData
    context->Unmap( buffer, 0 );

With C++ RAII, you can do something like that instead:

    MappedBuffer mapped{ buffer }
    // Write memory address pointed by mapped.pData.
    // No need to do anything else, the destructor of MappedBuffer will unmap.

This. Freeing memory is the least important job for destructors.

> I do write games and game engine code and tools in C++ without using any of the OOP features.

Excuse my C/C++ ignorance, but why not simply use C?

Because c++ without OOP still gives you RAII (which is neutered a bit if you don't write your own classes but still), safe pointers, references, lambda, and an immense standard library, to name a few.

C++ RAII is completely gone without the use of classes; it requires something with a destructor.

I guess the OP means pod types (plain Cish structs) where dtors are implicit.

But then what's left of RAII? What resource is there to allocate other than the memory itself? RAII means more than just "get memory to put this in".

Presuming GP includes unique_ptr, there's no real loss of RAII. In my opinion you might as well write trivial classes, but hey, to each his own.

That but without using any of the standard libraries. Even RAII can get in the way.

If by safe pointers you mean unique_ptr etc, I'm pretty sure those are classes: https://en.cppreference.com/w/cpp/memory/unique_ptr

So by definition require OOP?

OOP is such a nebulous thing. Just because the word 'class' is used doesn't mean something is OOP. Those smart pointers don't use inheritance, they don't implement any interfaces, no virtual methods...

I would call that using a subset of OOP features[1], not avoiding it entirely.

But I guess there's no point in arguing over semantics.

[1] As Wikipedia defines OOP: "a programming paradigm based on the concept of "objects", which can contain data, in the form of fields (often known as attributes or properties), and code, in the form of procedures (often known as methods)." https://en.wikipedia.org/wiki/Object-oriented_programming

It's not classic OOP without inheritance and virtual functions.

But nobody seriously uses virtual functions anymore, except where they would need to use function pointers, and for precisely those uses virtual functions are way better: cleaner, safer, often faster.

There is still the STL, there are still templates and data structures have a very well-defined lifetime.

Isn't the STL mostly classes? How is that not OO?

STL has nothing to do with OOP . In Alex Stepanov (the ST in STL) words "object orientedness is almost as much of a hoax as Artificial Intelligence"

Well, yes you have some objects in there. But it is rather an implementation detail. You don't use inheritance for instance.

I use string and stream, also most libraries (glew) and compilers (MinGW) that are updated use C++.

To avoid cache misses you can't use OOP, that's probably where this wave of going back to C is coming from:

For example here's how someone that knows how computers work writes Java games: http://www.javaonthebrain.com/java/warp/warp.java

If C gets operator overloading and RAII, there will be no good reason to use C++ for me!!

Only operator overloading is really important and would cut down the size of code written substantially. Thats the only real advantage of using C++ vs C. Everything else oop, function overloading,RAII,etc can be replaced with macros and structs.

Pretty sure you can't make destructors with macros?

Is RAII in C a serious suggestion being made anywhere?

GCC has it as an extension. See the cleanup attribute:

https://gcc.gnu.org/onlinedocs/gcc/Common-Variable-Attribute...

It is meaningless without destructors and exceptions.

Handmadehero started as C but transition to C++ AFAICT ?

There is no classes, extremely rare use of templates in the Handmade Hero code.

C++ with structs and 99% procedural code is actually very close to vanilla C.

Let's not be pedantic here.

Classes and structs in C++ are almost the same thing with the exception of the default member visibility, unless you mean a POD?

It was C++ from day one because he intended to use operator overloading

I think he is the perfect example of why I don't care what those C (or minimalist subset C++) programmers have to say. When you actually see how he works, how much time he spends debugging his messy code. They are all sooooooo far away from what I would describe as remotely good, clean code. And all so full of themselves too of course.

I liked Handmadehero for this reason, he is so arrogant and certain about how to properly write code, but when you actually see how he codes, what mess he produces and how long he spends live debugging it all the time. He constantly finds bugs in code he wrote earlier, etc. Yet he is so totally unable to find anything remotely wrong about the way he does things, and that there might have been some ideas invented in the last 30 years that could make him more productive.

I have zero respect for those types of programmers. I would quit any job instantly if I ever had to work with guys like this.

I don't know, he seems extremely productive to me. A lot of the time he spends in the debugger is more of him trying to figure out exactly what is happening with an api or memory usage rather than trying to figure out something he coded "wrong".

wow. You must be a prolific game programmer like Casey Muratori, right?

You understand that he is an extremely successful programmer in his field and has the respect of thousands of programmers world wide?

Maybe you can share some of your accomplishments with us.

Care to provide some examples and explain how using more abstractions would have solved them?