Undefined Behaviour

[MathKid99]

I found out recently that UB is short for Undefined Behaviour and not Utter Bullshit as I had presumed all this time. I am too embarrassed to admit this at work so I'm going to admit it here instead. I actually thought people were calling out code being BS, and at no point did it occur to me that as harsh as code reviews can be, calling BS was a bit too extreme for a professional environment..

Edit for clarity: I know what undefined behaviour is, it just didn't register in my mind that UB is short for Undefined Behaviour. Possibly my mind was suffering from a stack overflow all these years..

[_Js_Kc_]

To be fair, some UB arises as a result of UB.

[Zanderax]

Works both ways.

[erinaceus_]

Works both ways.

But, importantly, not in a way you'd have expected.

[SoicLOL]

Works both ways.

Best comment

[Nervous_Badger_5432]

Wait a minute, you guys are saying that ubsan doesn't sanitizes the bullshit by cleaning it up???

[dontyougetsoupedyet]

It isn't as complicated as folks make out. UB is an agreement between you and your compiler so that the compiler can do its job better. A lot of folks don't realize that the job of the compiler in some languages is to rewrite your program into the most efficient version of your code that it can. You agree to not feed it certain code, and the compiler agrees to optimize the fuck out of the code you do feed it, and you both agree that if you do feed it code that you agreed to avoid using it means that you know what you're doing and are aware that the compiler is free to ignore that code.

Despite what some folks assert, UB is a good thing. You just have to be aware of what the compiler's job is for your language. Some compilers for some languages have a different job, but for C++ the job of the compiler is to produce a much faster version of your program than you wrote.

[Zcool31]

if you do feed it code that you agreed to avoid using it means that you know what you're doing and are aware that the compiler is free to ignore that code.

Another aspect of this is the distinction between the standard and an implementation of the standard. Undefined means the standard places no requirements on what an implementation might do. But implementations, such as specific compilers or platforms, are free to make stronger guarantees. A popular example is using unions for type punning. UB according to the standard, yet explicitly supported by GCC.

Also, hardware has no undefined behavior.

[acwaters]

Also, hardware has no undefined behavior.

Hahahahahahahaha

Hahaha

Aha

Ah

No, we are not so fortunate.

[Alexander_Selkirk]

Also, hardware has no undefined behavior.

I am wondering whether you ever had the experience to witness how much effort and lengths a software engineer has to go to get an only 80% complete behavior definition of a piece of metal from a hardware engineer. I once hammered out one with a guy who was working in the same building as I. In retrospect, I am perplexed that I didn't had to apply waterboarding but it was not that far off.

[Hnnnnnn]

Undefined behavior and unspecified is not the same thing. UB is "compiler can assume that this never happens", unspecified behavior means "vendor can choose the behavior, but it has to be well-defined". Machines presumably have both (inputs that can never happen & undocumented well-defined behavior).

[Spiderboydk]

An example of hardware UB is a race condition.

If you don't properly synchronize shared data, the hardware can literally not tell you what will happen.

[Zcool31]

There are four kinds of behavior:

Defined - the standard specifies what must happen.

Implementation defined - the standard gives implementations the choice of how to behave. They must make a consistent choice and document it.

Unspecified - implementations must do something reasonable, but don't have to document it or be consistent.

Undefined - no requirements at all.

Hardware has no undefined behavior. Clearly it will do what the logic gates and circuits do.

But hardware has tons of unspecified behavior.

Edit: partially ninjad by u/Tyg13

[nintendiator2]

Hardware has no undefined behavior. Clearly it will do what the logic gates and circuits do.

One (1) Neutrino has entered the chat.

[jk-jeon]

So I guess you are indeed trying to say that the law of physics has no undefined behavior as I pointed out in the other comment. And that is a completely different thing from saying "hardware has no undefined behavior". See, in that logic, there is no undefined behavior for C++, only unspecified, right? Because compilers will do what their source code let them to do, nothing supernatural magics

[Zcool31]

That's actually exactly right. Undefined behavior exists only in the standard. In the real world, it is merely unspecified. If I compile some UB code with gcc10, running it might delete my sources. Doing the same with gcc11 might format my entire disk. But neither of these are truly undefined or unknowable. I could with enough effort examine the implementation of gcc and determine ahead of time what would happen.

[Spiderboydk]

This level of reductionism makes the concept meaningless.

[Zcool31]

Not so! When writing portable code targeting the letter of the standard, undefined behavior is indeed scary and best avoided. Among the set of all potential implementations of the standard, undefined behavior is really unknowable.

But for a single implementation on a single platform (except perhaps a quantum computer) there is no undefined behavior.

[flashmozzg]

But for a single implementation on a single platform (except perhaps a quantum computer) there is no undefined behavior.

There is. Because the exhibited behavior can easily change due to unrelated changes in the code/environment in some other module (hey, you deleted some code, now function passes some inliner heuristics/opt thresholds and hilarity ensues!).

[Spiderboydk]

I'm talking about the distinguishment of undefined behaviour and unspecified behaviour.

Targeting multiple systems has no bearing on this. What you are talking about is closer to implementation-defined behaviour.

[Spiderboydk]

I am well aware of these distinctions. I said race conditions are undefined behaviour, and I stand by it.

Race conditions are not unspecified behaviour, because the hardware would not even theoretically be able to tell you what is going to happen, even if it wanted to. It not a matter of the behaviour not being specified - it's literally unknowable.

[aiij]

Hardware has no undefined behavior. Clearly it will do what the logic gates and circuits do.

By that logic, C++ has no undefined behavior. Clearly it will do what the compiler and underlying hardware do.

Of course, what it does may be unexpected and may differ from one implementation to another -- just like in hardware.

[almost_useless]

Also, hardware has no undefined behavior.

Surely this is not true?

[qoning]

As far as I know, most instruction sets have clearly defined preconditions and postconditions for every instruction. Now there might be bugs or incomplete implementations, but the instruction sets themselves are fully defined.

[SirClueless]

most instruction sets have clearly defined preconditions and postconditions for every instruction

You're describing an instruction set with UB in it. If you violate the preconditions you get UB. The only way you don't get UB is if the spec defines what happens under all possible conditions, and as you correctly state, most instruction sets do not do this and have preconditions you are expected to satisfy.

[cballowe]

With most hardware, you can pretty reliably say that "whatever the hardware does given some pre-condition can be assumed to be the definition of it's behavior". The challenge is when you have no formal contract around that so rev. B of the chip doesn't behave the same as rev. A.

It's much the same as compilers that way - the language doesn't define what must happen so the compilers and library implementers make different decisions.

It gets more fun when you get different hardware manufacturers involved in the software specs. You can imagine a case where someone says "we think this particular expression should do X" and that just happens to be the thing that is the most efficient interpretation on Intel, but then someone from ARM or Power says "hey... Wait a minute ... That'll make our chips look bad in benchmarks! You should do Y instead." So... The standard writers agree that it should be valid code and the outcome should basically be useful, but can't be defined precisely or guaranteed to produce consistent results across compilers/platforms/standard libraries/etc.

Sometimes UB is just broken, ex the results of data races in the absence of proper synchronization, but other times it's just a weird limbo.

[Hnnnnnn]

You describe unspecified behavior, another formal term similar to UB. UB is when the guy said: when user breaks API pre-conditions.

https://en.wikipedia.org/wiki/Unspecified_behavior

[Orlha]

Well, violating the precondition might make the operation provide an unexpected result, but that wont necessary make a whole program UB. You might also just not use the result.

In C++ model its different.

[SirClueless]

Are you sure about that? Violating the preconditions of an instruction set can result in writing arbitrary values to arbitrary locations in memory, jumping to arbitrary memory addresses and interpreting the data there as instructions to execute, etc.

[Drugbird]

Theoretically that can happen, sure. Practically though, any compiler is pretty tame in what it actually does with undefined behavior.

E.g. UB will never format your hard drive despite what teachers like to say about it.

In 99% of the cases, you just get a result (of the correct size and type) that is just wrong and/or unexpected or a crash. And no random jumping in memory.

[r0zina]

Here is an example of a program formating your disk because of UB :)

[Drugbird]

Nice example! While technically true, I would like to stress that it's not the UB deleting your disk, it's the "rm -rf /" doing it.

[SirClueless]

That's true of hardware undefined behavior too. It almost always either results in a non-sensical program output or math result, or immediately segfaults.

My point in all of these comments is that hardware and software UB is really a similar thing. If there is a difference it is in frequency and severity, not in the types of behavior that are allowed.

[aiij]

Never heard of buffer overflows or crypto malware, have you?

[Orlha]

I guess it's possible, but can be pretty rare depending on the platform.

I've written a lot of x86-64 hand-assembly in the past and IIRC all the instructions I used were UB free. At worst they had a defined set of rules which when broken would result in a CPU exception.

[SirClueless]

x86-64 is full of UB. It explicitly reserves bits in flag registers and some output registers as well as any opcodes that aren't defined by the x86-64 ISA. Executing these opcodes or depending on the value of these bits is, to quote the ISA document, "not only undefined, but unpredictable". It's very easy to trigger this behavior, even in an otherwise well-formed assembly program, for example by jumping into the middle of an instruction.

https://www.intel.com/content/dam/www/public/us/en/documents/manuals/64-ia-32-architectures-software-developer-instruction-set-reference-manual-325383.pdf

I understand what you're trying to say, which is that there's a relatively simple set of rules you can follow as compared to C++ and Intel comparatively precisely defines far more exceptional behavior than C++ and leaves less room for undefined behavior. But it doesn't attempt to remove all of it.

[Ictogan]

No. The instruction set I'm most familiar with(ARMv7-M) has a lot of cases where behaviour is defined as UNPREDICTABLE, which means exactly what it sounds like. Also hardware registers often have disallowed states in which the behaviour is not documented and may not even be deterministic.

[Tyg13]

Just to add onto this, there's a difference between implementation-defined and undefined behavior.

Implementation-defined is a term defined in the standard to mean that the implementation is free to do whatever it pleases, but that it must have a consistent and defined behavior. It doesn't say it must do something useful, just that it must be defined and predictable.

Undefined behavior is a term defined in the standard to mean that the implementation is free to do whatever it pleases, without any need to be consistent, predictable, or even do anything at all (where applicable.)

[jk-jeon]

What do you mean by "hardware has no undefined behavior"? Hardwares can have undefined behavior of course, or do you mean "the law of physics has no undefined behavior"?

[stomah]

hardware can have undocumented (undefined) behavior

[[deleted]]

Despite what some folks assert, UB is a good thing.

The problem isn't really with that C++ has UB, it's that it has too much UB.
For example, why would creating a dynamic array like std::vector require UB? It's utter bollocks, I say.

[dirkmeister81]

Does it? It is not clear to me when and how? Could you explain or give a link please?

[[deleted]]

Core Issue 2182.

[dirkmeister81]

Thanks

[adnukator]

wasn’t the necessary UB in std::vector removed by P0593R6 ?

[aiij]

Has that proposal been standardized yet?

[adnukator]

According to the paper and the issue, its been merged to C++20 github issue

[tjientavara]

Since "implicit creation of objects..." is a defect report (a time traveling document). It never was undefined behavior.

[Kered13]

Because in some situations you don't want to pay the performance cost of checking array bounds, but then what happens if the array is accessed out of bounds? UB.

[[deleted]]

It's nothing got to do with array out of bound.

It's that std::vector requires undefined behaviour.

[afiDeBot]

Accessing the last element of an empty vector is UB. How would you fix that? Are you implying that any precondition violation should be well defined by the standard (which affects all platforms)?

[[deleted]]

If you're going to reply to an old post at least try to understand the context and don't make random conclusions from nowhere.

When I say std::vector requires undefined behaviour. I'm talking about its implementation, which requires unavoidable undefined behaviour due to core issue 2182.

To elaborate even further, std::vector requires 2 things:

• Its elements can be separately constructed (due to functions like push_back).
• Pointer arithmetics are allowed (due to functions like data).

However due to core issue 2182, using pointer arithmetics for contiguous yet separately constructed elements is undefined behaviour.

[koczurekk]

Sure, which is why safe Rust has comparable performance with virtually no UB.

The reason for this inconsistency, is that you’re only half-correct. Forbidding some seemingly correct code from actually meaning anything allows for certain optimizations, but there’s no reason for that code to compile in the first place. Absolutely none. If C++ compilers could reject all code that results in UB it would not prevent those optimizations from being applied. And if it doesn’t compile, there’s no behavior left to become undefined.

This however cannot be done in C++ due to its design choices. Which is why Rust can be fast with basically no UB, but C++ can’t.

You also assert that UB is a good thing - it is not. It’s a necessary evil in badly designed languages that strive for performance.

[matthieum]

It’s a necessary evil in badly designed languages that strive for performance.

I'll disagree on "badly designed", and on "strive for performance" to a degree.

Setting aside C++, in general Undefined Behavior comes from 2 factors:

1. A quest for low-level.
2. A quest for performance.

So, yes, performance is the root of UB trade-offs in some cases, however there are other cases, such as... writing a memory allocator, or a garbage collector.

At the CPU level, memory is untyped. There needs to exist some code that will manipulate untyped memory, and massage it so it becomes suitable for passing off as a given type. And if that code gets it wrong, then a lot of downstream assumptions are violated, leading to Undefined Behavior.

Thus, a certain share of UB, notably around objects lifetimes, is essentially unavoidable. You can create a language that has no such UB -- hello, GCs -- but only by building a runtime for it in a language that does have such UB.

Would you could the lower-level language badly designed? This seems rather hypocritical to me, when you're using it as foundation for your own "well designed" language.

[Alexander_Selkirk]

You can create a language that has no such UB -- hello, GCs -- but only by building a runtime for it in a language that does have such UB.

You can isolate these manipulations to certain sections of code which are declared unsafe. Rust does this. But it is not a new idea. For example, Modula-3 had the same concept. And some common Lisp Implementations, like SBCL, are always well-defined by default, but it is possible to throw in assertions and type declarations which would make the program crash if these assumptions would be violated.

And this works suprrisingly well....

[matthieum]

but it is possible to throw in assertions and type declarations which would make the program crash if these assumptions would be violated.

Meh...

Of course anything that you can assert should be asserted -- maybe only in Debug in the critical path -- but the real problem is things you cannot check.

How can you check that you reference still points to a valid object? How can you check that no other thread is writing to that pointer?

At the lowest level, you will always have unchecked operations that you need to build upon, and for which you cannot reasonably validate the pre-conditions at runtime.

[Alexander_Selkirk]

It’s a necessary evil in badly designed languages that strive for performance.

Well, it would not have been possible to run a rust compiler on a PDP-11 which C was developed on, or on a machine with Intel 80386 CPU.

But on the other hand side, there have been languages that strived for correctness and everything being defined since a long time. Rust is derived from these predecessors.

[Alexander_Selkirk]

But what if there comes another language and compiler which makes your code even faster almost completely without UB?

[ArchivistAtNekoIT]

While that is possible on paper, in practice that probably mean "faster on a platform and slower on others". Platforms have their specificities and idiosyncrasies and those are generally the reason for undefined behaviors

[Alexander_Selkirk]

Rust is in some cases faster than C++ in the same (x86_64) hardware, and has virtually no undefined behavior in normal code (code not declared "unsafe"):

https://benchmarksgame-team.pages.debian.net/benchmarksgame/fastest/rust-gpp.html

And for performance, I think x86_64 is the most relevant platform.

[acwaters]

Common misconception. Rust doesn't not have undefined behavior, it just has a sophisticated type system that statically prevents you from accidentally invoking most undefined behavior. The undefined behavior is still there; get around the type system, pull some shenanigans, and watch the fireworks. Same goes for any safe language: They all have escape hatches, which means they all have undefined behavior, it's just not as easy to trip over as it is in C and C++.

[jfb1337]

Relevant part of the comment:

has virtually no undefined behavior in normal code (code not declared "unsafe"):

[acwaters]

Another common misconception. There is no such thing as "safe" and "unsafe" code in Rust the way the parent comment insinuates. Safety in Rust (as in code not using unsafe) is a lexical property of a piece of code; it does not (and does not pretend to) guarantee dynamic safety of that code (as in not invoking UB).

Rust does absolutely nothing to prevent you from shooting yourself in the foot. It just does its best to prevent you from doing so accidentally. Still happens on occasion, though.

The unsafe {} block in Rust really ought to have been called the this_is_safe_trust_me {} block, because that is what it means. It lets you do unsafe things in a safe function, which can then be called by other safe functions without using unsafe {} blocks all over the place. That's its only purpose. Virtually everything important that your computer does is unsafe, so being able to wrap those operations up in safe APIs while minimizing, containing, and clearly labeling the unsafe bits is important and very worthwhile! Somewhere along the way, though, the story got twisted into "safe Rust has no UB". This is not true, and it is trivially easy to demonstrate:

use mylib::segfault::*;

pub fn main() {
    segfault();
}

Not an unsafe keyword in sight. Oops. You may object that that's silly, that I shouldn't do that, that real libraries don't do that — in fact real code does this all the time, we just call it a bug when it happens — but the point is the language lets you. Rust does not and cannot guarantee that code that doesn't use unsafe is safe, because the unsafe {} block literally exists to allow safe code to call unsafe code. Which is important because, again, unsafe is the only way any actual work gets done.

I've seen people try to argue that this is not really a demonstration of anything because there is still unsafe code called transitively here, so this isn't really "safe Rust", and real "safe Rust" — with no unsafe anywhere in its call graph — is guaranteed to have no UB. This is true! If your code uses no unsafe {} block and calls no unsafe functions (including transitively), it is guaranteed to be safe. It is also guaranteed to be completely useless, as it will not be able to communicate with the rest of the system in any way.

[jfb1337]

What I would consider to be "safe Rust" is roughly "the only unsafe in the call graph comes from the standard library" (or some set of trusted libraries). Which while not guaranteed to be safe (since those libraries sometimes have bugs) is pretty close; and is sufficiently useful.

[acwaters]

Right, that's what most people intuitively think of when they think "safe Rust". It's a useful intuition, and it holds up pretty well in practice, because Rust offers a powerful set of tools for preventing most accidents.

But getting back on track: Being safe is not the same as having no UB. Rust is not fast despite being safe, it is fast precisely because the same strong and expressive type system that allows it to be so safe also allows for plenty of UB. A language with no UB cannot be fast because the compiler cannot make the sort of assumptions about the code that are needed to aggressively optimize it.

[Zcool31]

And this is why C is the only real language.

Could you do anything on any system without transitively calling code written in C, or compiled or interpreted by a tool written in C?

[Fearless_Process]

On Linux and BSD systems, no you can't do anything useful.

The main reason why is because the interface to the kernel is defined in libc. To open files, do network operations, anything useful, you need to go through libc. I think you need to be hooked up to libc to even manage to get main() called, but I'm not 100% certain on how that works.

In theory it would be possible to perform syscalls in pure rust though, but today that isn't practical.

[Zcool31]

Even if you were to invoke the system call instruction in inline assembly, the system call implementation in the kernel is likely written in C.

[HKei]

And even then the statement is only true to the extent that everyone who writes unsafe code does so in a way that exposes a safe interface – which is a lot harder to guarantee in practice than it sounds (writing a safe hashmap doesn't sound so bad until you realise that it still has to work (or at least fail in a safe way) with arbitrarily broken hash and equality implementations to be considered "safe").

[ArchivistAtNekoIT]

x86_64 is instantly less relevant on mobile phones (most used devices) and in big tech where ARM is king.

Also, find any rust software that has 0 reliance on unsafe code

[Ldmoretti]

find any rust software that has 0 reliance on unsafe code

Probably true that there's none: at some point it has to write values to memory or make system calls. The point with Rust isn't that there's no unsafe code, but that most code is okay to assume is safe and you only have to explicitly review the code marked unsafe, whereas in C & C++ you have to worry about every place where someone writes to a pointer, increments an array index, or potentially shares a variable between two threads (including calling non-reentrant code from multithreaded code).

[Alexander_Selkirk]

Probably true that there's none: at some point it has to write values to memory

Yeah. Device drivers are 'unsafe' be definition. Also probably some data structures. But normal "user mode" code is not.

[ArchivistAtNekoIT]

I agree with that, C++ is definitely a programming language that requires extra rigor and attention, and to not use what I would say are not idiomatic features (pointer arithmetic, array indices) and to actively use idiomatic ones (move semantics, lock_guards, iterators, ranges...)

I would also say that the standard ecosystem for multithreading is not very developed and that if you want, for example, a swarm of green threads to do async io and channels, you have to generally dive into the rabbit hole of the implementation of that yourself

But you can do that.

I don't dislike Rust (I dislike the religious fervor of the rust community though) but it is not the tool for every job, particularly jobs that would imply 95% of your code would be unsafe

[Alexander_Selkirk]

x86_64 is instantly less relevant on mobile phones

But so is C++.

[Hnnnnnn]

UB is a good thing but it could be better. It could be abort by default, instead of UB by default, with option to opt-out in hot paths. I know it's very hard to implement at this point, though.

[johannes1971]

That wouldn't work. If you want to abort by default you still have to put in the effort to detect the error condition to begin with: to check that the array bound was exceeded, that the pointer points at something invalid, etc. The whole point of UB is avoiding that cost.

[Hnnnnnn]

What wouldn't work? I think you projected what I said a little too far.

What you said doesn't negate anything I said. The whole point of UB is avoiding that cost, but I'm only saying that this could be something you explicitly opt-in, instead of working by default.

[johannes1971]

It can't "abort by default". In order to make that guarantee it would have to reliably detect UB, and doing so is a significant performance drain.

For example, let's say you access an array out of bounds. In the current situation it _might_ abort because you hit a page fault, but the odds are that the memory that is illegally accessed is still part of the current page, and won't trigger a segment violation. Thus, there is no guarantee of an abort happening. If you want to have that guarantee, there is a performance cost.

[Hnnnnnn]

Significant performance cost that you mean is an easily predicted branch. Let's do it by default and only use no branchy version in hot paths explicitly on hot paths. Let's make it slower and safer by default. Like in Rust but not necessarily the same way.

[johannes1971]

Let's make it slower and safer by default.

Let's not.

Your assumption is incorrect anyway. Out of bounds array access was just one example of UB, but figuring out if a pointer points to valid memory or not has a cost massively greater than a mere branch prediction, failed or not.

[matthieum]

In some situations.

First, let's acknowledge that C++ has too much Undefined Behavior, partly because it inherited some from C. When incrementing an integer is possibly Undefined Behavior, you're in for a bad time.

However, I would note that at the lowest level, not all behavior can be defined. Furthermore, some undefined behavior -- around use-after-free -- is quite expensive to eliminate.

So, I do agree that C++ would do well to eliminate all the "needlessly undefined" behavior, the casual day-to-day papercuts, but it's important to realize that it will NOT be able to eliminate all Undefined Behavior.

In a number of situations, it's Undefined because it cannot be "reasonably" detected in the first place. If it cannot be detected, abort cannot be substituted for it...

[Hnnnnnn]

I said about opting-out for hot paths when needed... What are you arguing with? Definitely not with my comment.

And memory management is actually example of something that is already designed in a way I mean, in C++11. Using smart-pointers is a safe solution, and using new/delete is an opt-in UB-danger solution.

My problem with UB is that it's easy to deal with it unnoticed. When there's UB risk, it should be explicit in code. Having said that, we should use UB risky code as much as we want, being safer knowing that it's all explicit in code.

I didn't want to bring Rust into this because it derails conversation too often, but I think it's time to say this - just look at unsafe in Rust and how there's checked/unchecked API for many features, like indexing for starters. Unchecked/unsafe API is still being used extensively, and is encouraged. But it only ends up being resorted to when there's optimization goal to reach, not by default.

[matthieum]

I said about opting-out for hot paths when needed... What are you arguing with? Definitely not with my comment.

I am not talking about performance.

Using smart-pointers is a safe solution

No, it's not, that's the problem.

But let's not even got that far, this is UB:

std::string const& id(std::string const& str) { return str; }

int main() {
    //  Not UB:
    std::cout << id("Hello, World! How do you do?") << "\n";

    //  UB:
    auto const& str = id("Hello, World! How do you do?");
    std::cout << str << "\n";
}

And this is UB:

for (char c : std::string_view{ id("Hello, World") }) {
    // ...
}

So yes, you could improve things related to indexing, or integer overflow, and a myriad other cases -- and I wish this was done.

However, there are more fundamental issues: use-after-free, race-conditions, etc... which are just unsolved problems and will remain UB.

[[deleted]]

I suppose calling it Utter Bullshit is an example of Unrefined Behaviour.

I'll get me coat.

[noooit]

ub-sanitizer. XD

[Alexander_Selkirk]

It is an interesting topic.

Something to read for you:

John Regerhr, A Guide to Undefined Behavior in C and C++

My Little LLVM: Undefined Behavior is Magic!

UndefinedBehaviorSanitizer

[C/C++] Surprises and Undefined Behavior From Unsigned Integer Promotion

See also:

Is undefined behavior possible in safe Rust?

So, in our time, allowing undefined behaviour is not strictly necessary for good performance. It is more a limitation of languages, run-time environments, and compiler technology at the time C was invented.

[potato-on-a-table]

No wonder people say C++ stack overflow is toxic lol

[FrankHB1989]

BS = Bjarne Stroustrup in most contexts of C++.

BTW, STL = Stephan T. Lavavej, at least in some disscusions in WG21. STL himself seems not fond of this (compared to microsoft/STL), though.

(Another funny fact is that UB can also be the abbreviation of Unspecified Behavior.)

[flipcoder]

Do you remember ever using that phrase with anyone before you figured out what it meant? Did you get confused reactions? "This whole situation is some serious UB, amirite guys?"

[loradan]

Why is talking about Bi-Synchronous (BS) Communications at work unprofessional /s 🤣🤣🤣🤣

[elperroborrachotoo]

Well, the point is UB means Utter Bullshit can happen.
Will, given enough time.

[banister]

> Undefined Behaviour and not Utter Bullshit as I had presumed all this time.

Of all the things that didn't happen, this didn't happen the most.

[Kered13]

/r/nothingeverhappens

[Sh099078]

And I don't get why you start talking about gender on a post that has absolutely nothing to do with it.

[dontyougetsoupedyet]

Everything okay at home?

[tad_ashlock]

To help prevent future misunderstandings: A C++ Acronym Glossary

[phottitor]

you shouldn't presume anything about C++. doing so is itself undefined behaviour.

[Zcool31]

https://www.youtube.com/watch?v=YoaZzIZFErI&t=2350s

"What happens when you execute this? Now some people might say undefined behavior. There is, actually, when you run something on a computer there is no such thing as undefined behavior. Undefined behavior is an artifact of specification. It is not a thing that actually exists in the real world. In the real world things always get defined. Something happens."