Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Goodbye C++, Hello C

momentsingraphics.de

Post reply on HN
Print view View original

161–170 of 222 posts

Re: Goodbye C++, Hello C

#161

Post by skohan »

Thiez wrote: post #157
skohan wrote: post #152

Earlier quoted context omitted.

Yeah I guess it seems like a decent model for "safe" software would be sandboxed memory, and fine-grained file permissions. Arbitrary network traffic is a bit less dangerous - I mean someone could steal CPU cycles to process data and send it over network, but a safe language is not going to save you from that either. Most programs do not need arbitrary access to the file system, and it should be the OS's job to white…

> Most programs do not need arbitrary access to the file system, and it should be the OS's job to whitelist which files a program has access to. Again, a safe language is not going to save you from bad behavior on the filesystem either. It really only solves the memory problem. Except that it is often a memory-safety problem that enables an attacker to make a program misbehave, through things like buffer overflows. A…

Are we talking in circles here? My original point was that memory safety should be ensured by the OS/hardware. That way no matter how badly my program misbehaves, it will not be able to access memory outside of the sandbox. In other words, the CPU should not be able to address memory which has not been allocated to the current process. A buffer overflow should be a panic.

Even with a safe language, there's vulnerabilities like supply chain attacks which allow malicious code to use an escape hatch to access memory outside of the process. I.e. I could be programming in Rust, but one of the crates I depend on could silently add an unsafe block which does nefarious things. OS/hardware level sandboxing could prevent many such classes of exploits.

Re: Goodbye C++, Hello C

#162

Post by kaba0 »

forgotmypw17 wrote: post #72
jolux wrote: post #49

Earlier quoted context omitted.

> the general trend of nudging, cajoling more and more coders into using managed, very high level, safe languages and runtimes This is a good thing: these languages and runtimes are indeed much safer, and also much more productive than C. You can even still get the same amount of low-level control with Rust. > in general discouraging peeking under the hood, at the hardware level, as something raw, wild or unsafe. C i…

>What is the evidence for this? There are entire CLASSES of computing devices which you cannot put arbitrary code on without severe obstacles...

How exactly is it relevant to the topic? What does it have to do with ditching C?

Re: Goodbye C++, Hello C

#163

Post by kaba0 »

skohan wrote: post #141
Thiez wrote: post #131

Earlier quoted context omitted.

Then you'll be happy to learn that what you propose has been the case for consumer computers since protected mode was added to Intel 80286 processors in 1982. I think few people in this discussion are worrying about programs directly affecting other programs through memory unsafety, exactly because this doesn't really happen for software that isn't a driver or inside the OS kernel. The problem with memory unsafety is…

But I don't understand how data stealing can happen if each process is effectively sandboxed. If my process can't read or write to memory outside of what it allocated, how can I corrupt or steal user data?

In case of a browser, a buffer overflow can be exploited to upload user files for example — which are very much readable without trouble on most linux distros.

Re: Goodbye C++, Hello C

#164

Post by kaba0 »

skohan wrote: post #161
Thiez wrote: post #157

Earlier quoted context omitted.

> Most programs do not need arbitrary access to the file system, and it should be the OS's job to whitelist which files a program has access to. Again, a safe language is not going to save you from bad behavior on the filesystem either. It really only solves the memory problem. Except that it is often a memory-safety problem that enables an attacker to make a program misbehave, through things like buffer overflows. A…

Are we talking in circles here? My original point was that memory safety should be ensured by the OS/hardware. That way no matter how badly my program misbehaves, it will not be able to access memory outside of the sandbox. In other words, the CPU should not be able to address memory which has not been allocated to the current process. A buffer overflow should be a panic. Even with a safe language, there's vulnerabil…

> That way no matter how badly my program misbehaves, it will not be able to access memory outside of the sandbox

The problem is not about memory outside of the sandbox, but inside. Please read about return-oriented programming, for example, where a buffer overflow bug of a process can be exploited to hijack said process to do work it was not meant to do normally. If this error happened for example in sudo, it can very well be used to gain privileges and do real harm — and this whole problem domain is almost entirely solved by using a “safe” language.

Re: Goodbye C++, Hello C

#165

Post by kaba0 »

christophilus wrote: post #125
userbinator wrote: post #55

Earlier quoted context omitted.

"proven" sounds like cargo-culting dogma. The same was said of OOP in the 90s, and look what that caused. Hence my distrust of the snake-oil. Also, my real-world experience with wading through the abstraction insanity often seen in C++ (and justified because it's "safer") to find and fix bugs, and even more so with the sheer baroqueness of Enterprise Java (arguably an "even safer language"), shows that "reduce defect…

I think that if we focused on building small, simple programs that do one thing well and compose, C would be OK. It’s when we build out behemoths that you really have a hard time reasoning about your code. At that point, vulnerabilities are almost guaranteed. This is true in any language, but more so in unsafe ones. Maybe the suckless guys are on to something.

The complexity that must arise (otherwise the problem we are looking at is not interesting enough) will happen either way. Composing small tools will give you an ugly as hell glue code over them — just imagine a modern browser. Would it really be better to do curl and interpretJS and buildDOM and all these things? Just imagine writing the glue code for that in what, bash?

We pretty much have exactly that, but better with programming languages composing libs, functions and other abstractions. That’s exactly the same thing but at a different (better) level.

Re: Goodbye C++, Hello C

#166

Post by kaba0 »

oreally wrote: post #65
gravypod wrote: post #23

Earlier quoted context omitted.

"I know my software just works" is really hubris. The fly-by-the-seat-of-our-pants game industry has cranked up programmers egos and made them ignore a wide range of tools and practices that have been proven time and time again to improve developer velocity and reduce defects.

And on the flip side tech gets Leetcode interviews, shoehorned microservices when you dont need it, slow web browsers. The game industry iterates far faster and the result are programs that can handle far more features than the average tech methodology. It's the classic quantity leads to quality pottery grading experiment. Have you ever considered that these 'best practices' pile on so much unneeded crap that an expe…

I would not necessarily say that game development has better quality than web browsers. And the latter are anything but slow — they are engineering marvels no matter what you think of them. It’s just that websites like to utilize it shittily.

Re: Goodbye C++, Hello C

#167

Post by kaba0 »

bruce343434 wrote: post #115
acmj wrote: post #5

Earlier quoted context omitted.

You can go down the route to say C++ is largely a superset of C. You can always write C++ in the C way, so you don't see simplicity is an advantage of C.

> You can always write C++ in the C way Nope. They have grown too far apart. My C11 codebase simply does not compile when `mv *.c *.cpp && g++ main.cpp`.

That’s why grandparent wrote “largely”

Re: Goodbye C++, Hello C

#168

Post by woodruffw »

pjmlp wrote: post #137
woodruffw wrote: post #77

Earlier quoted context omitted.

> Look at all the locked-down walled-garden platforms proliferating I don’t think I’m getting the connection here —- Rust was incubated at Mozilla and is now managed by its own open-source foundation. There’s nothing particularly closed or “walled garden” about it. By contrast, Apple’s ecosystem is the canonical example of a walled garden. But it’s overwhelmingly programmed in unsafe languages (C, C++, and Objective-…

Actually GNU project is one of the culprits for C spreading into a world of that was already moving into C++ and other safer languages. > When you want to use a language that gets compiled and runs at high speed, the best language to use is C. C++ is ok too, but please don’t make heavy use of templates. So is Java, if you compile it. https://www.gnu.org/prep/standards/html_node/Source-Language... 20 years ago, it was…

> Actually GNU project is one of the culprits for C spreading into a world of that was already moving into C++ and other safer languages.

Both of these things can be true! GNU has advocated for C for some pretty asinine reasons. At the same time, they’ve ported all kinds of Lisp idiosyncrasies into their style guide.

Re: Goodbye C++, Hello C

#169

Post by CyberDildonics »

gravypod wrote: post #26
jolux wrote: post #24

Earlier quoted context omitted.

I fail to understand how that’s more explicit to be perfectly honest. If it’s hard to resolve where overloads are coming from then that’s a problem but otherwise it just seems more verbose for no benefit. Addition and multiplication are the operations in use here, why shouldn’t we use their operators to represent them?

In situations where the output's shape changes based on the operation this can be helpful. auto accumulate = ...; auto a = ... auto b = ... auto result = a*b; for (int row = 0; row This expression might be entirely valid when a and b are both 2x2 but then becomes incorrect when there's a different shape in b.

Do you mean type instead of shape? I also don't know what you mean by incorrect. C will also create casts when using two different number types in a math operation.

Re: Goodbye C++, Hello C

#170

Post by gwmnxnp_516a »

giomasce wrote: post #44
maleldil wrote: post #12

> Where C++ gives you many slightly different takes on the same concept (e.g. unique_ptr, shared_ptr and raw pointers), C gives you one way to go and that one has a conveniently compact notation (such as float ). You use unique_ptr and shared_ptr because float is unsafe. If you don't care about the safety that smart pointers provide, you can use float* in C++ too. > ticking with the example of matrix math, it is baff…

The problem is not even just safety. You can write safe C, if you are careful (and you need to be careful also for C++, smart pointers do not just magically make everything right). The point is that OP makes the point that C requires to write less code, and this doesn't even seem true: you have to remember, each time some non-trivial object goes out of scope, to call its destructor/deallocator, which results in a lot…

It is possible to write safe-C, but C is far more error prone than C++. C has more implicit type conversions than C++, which may results in bugs and undefined behaviours. C lacks RAII (Resource-Acquisition Is Initialization) that is useful for memory and resource management. C will actually require more code than C++ since, the C standard library lacks generic data structures such as vectors, hash maps, linked lists and so on. The implementation of those data structures requires lots of preprocessor macro hacks.

It is possible to write safe C, only if one uses static analysis tools and undefined behaviour sanitizers. In the case presented by the article, as it is related to game, safety does not matter much, unlike device drivers, operating systems or embedded systems where C bugs can introduce security vulnerabilities.

Regarding the compile-time complaint, it is possible to reduce the compile-time by using forward declarations; forward template declarations; template forced instantiation and isolating large parts of a project in a static library using CMake.

Post reply on HN