Hacker News Reader

Comment by youngthugger | Hacker News Reader

This makes C look like it's full of land mines. The minesweeper language.

In a certain way, it is. But for a lot of things C and (C++) is still necessary, and the fact that C is not safe is a requirement. Can you imagine the Linux kernel not being written in C? Just imagine all the overhead if the Linux kernel has to perform overflow checking after every internal integer increment.

Maybe some day Rust will be a good candidate, but that day hasn't come yet.

> Can you imagine the Linux kernel not being written in C?

No, only because the Linux kernel started as an UNIX clone and C is the UNIX's systems programming language.

Other OS were written in another systems programming languages. Before and after C got invented.

C only became widespread because a few successful startups in the 80's adopted UNIX for their workstation OS.

I'd say that in terms of seats sold, Borland and Microsoft had more to do with it. Maybe first one then the other. But 'C' was the semi-official language of the old DOS PC world from 1985 until Linux happened. It's somewhat tragic, because Modula-2 and Ada toolchains existed, but were harder to use than 'C' for performance and memory constraint reasons ( not to mention the toolchain costs )

Borland started out with Pascal, but went to 'C'.

>Borland started out with Pascal, but went to 'C'.

As someone that used all their products before they became Imprise or how it was called, I never saw this happening.

Even nowadays C++ Builder actually uses the Delphi framework.

EDIT: Just wanted to add that in my part of the planet, it was all about Assembly for systems programming, games and real applications. Turbo Pascal for general purpose applications without much performace issues and CLIPPER for the typical CRUD applications.

In the OS-programming world C/C++ is staple.

I am old enough to remember when it wasn't even an option.

Well I mean it kind of is. C's my favorite language but it's like a machete, simple enough, fairly easy to use and useful in a lot of places but if you don't know how to use it properly it's very easy to cut yourself with.

It's not the 80s anymore, there area many cases where there are much better alternatives to C.

But it's still a language you need for certain things, like responsiveness or real time applications. Like linus torvalds said it, C is like a more comprehensive assembly generator than anything else.

Having such a language allows you to change every little boring details to do exactly what you want. It has its use, and it's surely not intended to be mainstream as of today. But there are many cases where C comes back as a constant common denominator.

It's sure that it's kinda shitty that there's nothing really better than a language designed in the 70s, but I guess you could either blame language designers for not making anything better. There also are business/political issues and preferences for certain things that comes into play.

All in all, C just seems to be pretty good when you want to have code that works well with systems. Maybe there's just inertia as to where computer development is headed, which might be heavy related to C.

All I wish, is someday to be able to learn some more "virtuous" language like haskell, scheme, or smalltalk.

The 80's already had Mesa and Modula-2, but then those guys at Berkley had to create a few successful startups.

You may want to look up the age of those "virtuous" languages you listed. While it's fun to bash C, you could drive a damn yacht through the undefined behavior in Scheme. High-level languages are not immune here.

The title is making it seem as the listed behavior is largely unknown to C programmers. It isn't. And it is in the manual.

Yeah, hopefully if you are programming in C you'll know using an undefined variable is bad.

Yep. :-)

The article doesn't make much sense at times: Dereferencing a NULL Pointer: >>>contrary to popular belief<<<, dereferencing a null pointer in C is undefined.

I guess C programmers are not counted in the "popular" group.

I don't think it's wrong at all. I suspect if you asked a large number of even moderately competent C programmers, you'd find quite a lot of them believe it's defined to trap. That's exactly what the rest of it is talking about. Never mind the issue raised of how it potentially affects optimization, which I think very few C programmers would actually be able to speak to.

Are you really sure that most C programmers know about this?

IMO, if you'd ask the question "what happens if you dereference a NULL pointer", most C programmers would answer "a segfault".

That, of course, would be a leading question. Most people would probably tend to assume that you're asking "in the environment in which we're programming, what happens if you dereference NULL?" which is not what you meant.

I didn't poll my coworkers either, but at least I think the answers would be different if I asked "what does C say should happen when a NULL pointer is dereferenced?".

Perhaps that's just wishful thinking on my behalf, though. :)

I don't think that's particularly wishful thinking, however, your alternative phrasing could be seen as equally, if not more, leading.

When quizzed on the behaviour of a C program I would expect a careful and experienced C programmer to consider the behaviour described by the standard (which standard?); unspecified and implementation defined behaviours; and deviations from the standard in both the compiler and the environment. Often I'd expect the answer to be "it depends".

I think, once you unanimously conclude that something should not be done, that people don't really care _why_ it shouldn't be done until someone tries to suggest you should do it.

For example, we know not to dereference null pointers. It is pretty much never correct to do so, and it's hard to imagine otherwise. What does it matter what C says should happen when you do it? You're never going to intentionally do it, so it becomes an incongruous hypothetical. Like "what would happen if you were never born?" The answer is useless because the question is inherently flawed.

Good point. Some embedded environments will have different behavior. I don't recall what happened under MS DOS or if MS compiler provided an debug option.

Clang, for example, will optimize out some NULL dereferences. So even in real environments that people use, "it segfaults" is wrong.

Edit: some NULL dereferences.

In that case the machine code generated doesn't dereference NULL, so the answer "it segfaults" isn't wrong.

In the C code, a null pointer is dereferenced. A segfault is not happening in the executable. Arguing about intermediate steps is kinda moot IMO.

The very concept of dereferencing doesn't exist at that level.

I'll take the downvote as a request for elaboration. In C, you dereference a pointer. This typically translates to machine code that loads memory at an address. The translation is so direct that we tend to think of them as identical, i.e. dereferencing a pointer is loading memory at an address. But this is not so; first of all, nothing says pointers have to be implemented as memory addresses in the first place, and even if you do implement them that way (as virtually every C implementation does), not every pointer dereference has to generate a load instruction. That's not just the case for optimizing out NULL dereferences. Optimizations mean that in general, an expression p can have the memory load optimized away if the value at that location is already known from a previous computation (say, because you just assigned a value there, or you read the value a bit earlier and it's still available in a register).
In C, you deference a pointer. In assembly or machine code, you load memory at an address. The two don't have to happen at the same time, though, and just because you don't end up loading memory at an address doesn't mean you didn't dereference a pointer.
In short:
*(char *)NULL
This always dereferences NULL, even if the compiler optimizes out the statement entirely.

If you are in a company that codes largely in C, do a pool and report back. I'm honestly curious.

Unfortunately, I don't work in such a company.
A completely unrepresentative poll among two C++ programmers showed that 50% thought it was a segfault, whereas the other 50% suggested it could be undefined behavior, deducing that from the knowledge that the behavior is different in Linux userspace and kernel.
Although I wouldn't call those two typical C++ programmers. They do security CTFs for fun, so they might have a broader knowledge about exploitable behaviors in C/C++ code.

For a while you were actually able to mmap the memory at address NULL under linux, which is usable for exploiting (you can pass arbitrary data to kernel code that you can bring to dereference null pointers)

Wouldn't virtual address translation prevent this from happening?

I recommend reading the articles linked elsewhere in this thread:
https://news.ycombinator.com/item?id=8879948
A lot of this is C compiler writers using the spec to perform counterintuitive "optimizations" (with dubious performance value), and forgetting that they're writing software for C programmers to use, not trying to win a pedantry war with them.

Reply on news.ycombinator.com