Hacker News Reader

Comment by coliveira | Hacker News Reader

The reason why safety in C++ is difficult to achieve is due to the memory model used by C and C++. The memory model is a flat space provided by the OS that can be addressed by pointers. In this sense, C++ is similar to assembly code. A language like Java, on the other hand, assumes a different model where you can only access objects with well defined behavior. To change this, one needs to disallow the use of native pointers in C++ or make them less powerful, like Java did.

View on HN

> The memory model is a flat space provided by the OS that can be addressed by pointers

From what I understand this is not true. Pointers cease to be valid the moment you try to leave a single allocation. You get to play around within a single continuous allocation and one past the end, everything further out is playing with fire.

Even comparing the "addresses" of two separate allocations is undefined if done with "<" . The comparison function std::less is basically magic to get well defined behavior out of a language that doesn't guarantee it.

> C++ is similar to assembly code

Only if you use a compiler that does not optimize anything.

> Pointers cease to be valid the moment you try to leave a single allocation.

For the other readers who might not know what this is referring to, it's pointer provenance. For an introduction to the topic, I always recommend Ralf Jung's blog series, "Pointers Are Complicated":

https://www.ralfj.de/blog/2018/07/24/pointers-and-bytes.html

It is, for all practical purposes, a flat space in the sense that for bare pointers, operator++ is defined (increments to the next whatever, defined based on type of pointer).

There is no operator++ equivalent in Java to apply to object references (unless you go unsafe); you can't immediately shoot yourself in the foot without the compiler noticing by asking for "the next object after this one" when no such thing exists.

(handwave a bit: of course, you can ask for an object past the last object in any container. That's (a) not the same thing and (b) results in an immediate runtime error in Java, instead of undefined behavior)

> everything further out is playing with fire.

That's the point. C and C++ don't prevent you from playing with that for. Memory-safe language do.

Rust only requires you to wrap it in unsafe. And I think C# allows you to do some pretty crazy stuff too.

The Kestrel web server[0] is an example of a codebase that makes extensive use of C#'s unsafe functionality. UnmanagedBufferAllocator[1], for example, looks pretty similar to how you'd write it in C++.

[0] https://github.com/dotnet/aspnetcore/tree/1a56bdb671700ae698...

[1] https://github.com/dotnet/aspnetcore/blob/1a56bdb671700ae698...

C# cleanly separates pointers into Java-style managed references that are opaque, and C-style unmanaged pointers that are transparent but can only be used inside "unsafe" blocks.

It depends what you mean exactly. The C and C++ official memory model is very much not a flat space, but exactly what you describe for Java - you can only (validly) access objects. For example, the operation x < y is only defined if x and y are both pointers into the same object or array of objects (or one past the end of an array of objects). Otherwise, the operation is entirely undefined in both the C and the C++ memory models. The following program has no defined C or C++ semantics, and neither the C nor the C++ standards can tell you anything about what it could do:

  int x = 0;
  int y = 0;

  if(&x < &y) {
    printf("???");
  }

Now of course the implementation of C and C++ actually assumes without checking that you only access objects and not raw memory, and thus will happily read raw memory directly.

I really feel like it's a hell of a definitions dodge to say "This is what the model is" when no compiler implements constraints to require the user to treat the model like that (i.e. I can always just increment the pointer, or typecast it to numeric type, do math on it, and typecast back to a pointer, without having to pull any big red levers like using "unsafe" methods).

If it's undefined but it compiles to something, is it really undefined, or is the definition merely not standardized?

Yes it’s really undefined. There is a distinction from “implementation defined behavior” which you seem to be confusing it with. You are practically wrong in your assumptions. Since undefined behavior is undefined the compiler is free to do anything with compilation, it may compile to something but you have no guarantee what that something is. And in real life this often actually bites you when the optimizer comes into play - modern optimizing compilers can and do optimize undefined behavior into noops or other weird stuff.

Read this and don’t come back on this topic until you clearly understand it: https://en.cppreference.com/w/cpp/language/ub

No; this is a common misconception I see from people who swallowed the "it's allowed to format your hard drive and blow up your monitor" dodge vs. the electrical engineers who know where terminology like 'undefined behavior' originated in engineering. In practice, it tends to do something subtle and usually right but probably wrong for the simple, practical reason that if it did anything as obviously wrong as "format your hard drive and blow up your monitor," someone would have tripped over it testing the compiler and changed the compiler.

This is why I actually hate using this programming language, because when you hit undefined behavior (which the language makes trivial to do; incrementing a pointer past the allocated memory is a one-line operation that throws no errors) the end-result is usually subtle, wrong, and hard to find later if it isn't actually "close enough to right" because the compiler desperately tries to make a useful program because that's what compilers are for. Hell, if it formatted my hard drive and blew up my monitor, it'd be much easier to figure out where the problem was! Hand-waving this flaw in the design of the programming tool with "oh, it's undefined behavior; you should never have relied on that in the first place" when so many valid statements in the language compile to undefined behavior, as if that is good enough, is building a house on sand.

... and quite frankly, our industry is full of sand houses and we could stand to respond to the amount of undefined behavior in C++ by ceasing to build on that shaky foundation.

You are arguing against topics I never brought up. (I am an EE fwiw). I have no misconceptions where undefined behavior comes from and have demonstrated none thus far.

> This is why I actually hate using this programming language, because when you hit undefined behavior (which the language makes trivial to do)

Ok so you want to editorialize on something else entirely.

No idea how that dismisses anything I said or referred to.

Regardless of how trivial it is in practice to invoke undefined behavior it doesn’t change the real differences between undefined and implementation defined behavior.

Every undefined behavior is de facto implementation-defined because something happens resulting from the state of the machine and the code being executed. Change the implementation and the thing that happens changes.

(I know the c++ spec defines these terms differently; I'm not talking about the spec definitions and I never was. I'm saying the spec definitions are a dodge around what actually happens when code is compiled and executed).

I have no idea what your thesis is.

It seems to me that you’re claiming that the existence of undefined behavior is bad. Which isn’t actually that controversial outside of certain people weirdly infatuated with C/C++.

But it seems moreover you merely have a problem with it being called undefined behavior or something, as if the word itself isn’t harsh enough.

I don’t see it. I don’t see the problem with the definitions as stated. It doesn’t weaken any commentary about undefined behavior to me at least.

And again regardless of your hatred for C++ weenies it doesn’t change the fact that there are meaningful practical differences between undefined and implementation defined behavior, the distinction has to exist regardless of what you call them.

> Every undefined behavior is de facto implementation-defined because something happens resulting from the state of the machine and the code being executed.

Regardless of spec this makes no sense to me. Implementation defined implies something is still “defined”, like not in the spec but somewhere. Undefined means what it says - it’s undefined.

I don’t even disagree with your other points but I don’t get how complaining about the practical difficulties of avoiding undefined behavior have to do with a “definitions dodge”

> No; this is a common misconception I see from people who swallowed the "it's allowed to format your hard drive and blow up your monitor" dodge vs. the electrical engineers who know where terminology like 'undefined behavior' originated in engineering. In practice, it tends to do something subtle and usually right but probably wrong for the simple, practical reason that if it did anything as obviously wrong as "format your hard drive and blow up your monitor," someone would have tripped over it testing the compiler and changed the compiler.

This is incorrect. In one very popular web server, some behavior depends on the values set for some response headers, and the value is checked in part by calling a function like strstr which takes two pointers and two lengths and searches one string for the other string. If you pass {null, 0} as the haystack and the implementation of the strstr-like function starts by computing the upper bound of the haystack (null + 0) then the compiler can legally produce *any value* for that expression. Then your program will quite predictably segfault. When it does your recourse is to fix your program, not to fix the compiler, because the compiler is working correctly.

Oh, no argument here. All I'm saying is that the behavior resulting is determined by the current state of the machine and the compiler used.

Why does the distinction matter? Because I don't believe any program beyond minimal complexity written in C++ is actually free of undefined behavior. Therefore, being able to ask questions like " What configuration of compiler built this?" is meaningful for debugging code.

Because undefined behavior is so easily reached in the language's specification, the abstraction is broken from the start and one must know implementation details of the compilers used to understand how the code behaves.

The result of the pointer comparison is unspecified, this is not undefined behavior in C++.

I don't know about C.

One issue is that the memory model isn't just a flat space that can be addresses by any pointer value - it may look similar to one if your compiler and OS let you, but doing things like accessing memory allocated as a different type or outside (an array of) objects is invalid, and the compiler is perfectly allowed by the standard to assume that never happens and happily "optimize" everything that may be a result of that away.

A lot of bugs have been caused by programmers assuming any access to the 'linear address space' is fine, but that has never been reliable as it's not allowed by the standard. The worse thing is when it looks like it works for a while, but you're relying on stuff not allowed by the standard so may change at any time (like a compiler version or option change, or even a change to a different part of the code that happens to tickle the compiler's analysis stages a slightly different way). See the "Time traveling NULL-check removal" - as the compiler "knows" that no pointer can ever have the value of NULL during deference, any path that does that can be completely removed - even if there's something like a NULL check and a logging output before said deference, if compiler decides that deference will eventually happen in that path unconditionally, that path and logging before the deference Can Never Happen so can be removed.

Or type punning and pointer aliasing - objects are created with a type, and so the compiler Knows if you convert a pointer type to another type that isn't compatible with the first type, they somehow magically point to different memory, and all the assumptions that implies for the following code.

A lot of these restrictions are pretty similar to things like Java have - the difference is that the JVM checks and flags violations and/or straight up disallows them when compiling - not just allowing the compiler to (silently) optimize based on those assumptions, and throwing the result at hardware to see what happens.

There may be a few platform/compiler-specific behavior used to implement super low-level stuff like OSs, but that's platform-specific stuff outside the C++ (or C) spec itself.

That's pretty much what the article says though. "Don't use traditional pointers" is a fairly trivial rule to enforce via static analysis, and constructs like unique_ptr are syntactically identical anyway.

The bit that has me confused is that it's inventing a new term, "borrowing affine style", to describe a longstanding paradigm that has traditionally been called "RAII". Now, neither term is very clear, but surely it's better to use the existing confusing jargon instead of inventing new terms.

The significant difference is a static guarantee of no reuse after move, hence the 'affine' qualifier (which is not new).

borrowing affine style is more than RAII. borrowing affine style means that there are no pointers, and always one owner. in borrowing affine style your functions take a unique_ptr for everything, if the lifetime of the data needs to live beyond the function, then the function returns a unique_ptr of that data back.

    std::unique_ptr<foo> var;
    // init and use var
    var = SomeFunction(std::move(var));
    // use var again.

Note that while in SomeFunction you lose access to var, but since SomeFunction returns it again you don't really lose anything. Of course Somefunction can also return some other unique_ptr<foo> that isn't var and you can't control that.

It is an interesting idea, though I'm not sure if I like it for real world code or not.

I'm not sure this has much to do with RAII. RAII does indeed require affine types, but RAII doesn't provide memory safety. The article describes a method of memory safety.

(Also, I used the term "borrowless affine style" mostly because people might hear the term "affine style" and assume I'm talking about Rust, since that's what most people know.)

Affine in this case is referring to not being able to use values after they have been moved. When I say not able to use, I mean that it's a compile time error to attempt to use them.

C++ does not restrict you from using things after they have been moved and therefore does not have affine typing!

You just need an unsafe keyword.

Reply on news.ycombinator.com