I propose infinite timezones, you simply calculate the true noon from your latitude. Smartphones can do that for us.
The time at your workplace would be some minutes off the time at your home. And when your phone is off, you are screwed.
It's like in the old days before railroads when every town had it's own time, but even worse.
And they happen at every level and can combine beautifully. I had a DNS server flooded with Format Error messages, because NTP Pool DNS sent an invalid response for a specific query and two (yet to be identified) clients sent (and still send) that query every second or so, because the response never reaches them. And as the upstream query failed, the DNS server would send the same query every second again to a bunch of other DNS servers, every single response generating another Format Error. Dozens of log lines per second.
Those two generate about 1GB of waste traffic per month. And that's the two buggy machines talking to a small DNS server I manage. I wonder how many junk traffic public DNS servers generate.
Serverless is like AWS lambda, when you don’t have an explicitly running VM that you pay per time; instead your code is run in “a cloud” and you pay per invocation.
This is nothing new! “Serverless” is well defined and understood for years and years!
This is actually what Fly machines do under the covers. When you use it as a PaaS, the client CLI sets all this up for you, and then our proxy starts/stops things as needed.
IPv6 link-local addresses based on MAC address are neat, I use that in production.
We build a machine containing six cameras. All of them come with the same default IPv4 address, but the MAC address is based on the serial number, so the IPv6 address is, too. Employees enter the six serial numbers by scanning Datamatrix codes in order, and I can calculate the IPv6 addresses from that, connect and change their IPv4 addresses all in parallel.
Ten years ago I did the same thing on a different product with weird ARP shenanigans. The IPv6 approach is way faster and cooler.
What I don't get is, why are we still adding more undefined behaviour to the standard?
For example, C++23 got std::unreachable. From my dips into Rust, I expected something similar to std::abort, terminating the program in some sane and possibly helpful way.
However, in C++, std::unreachable just invokes undefined behaviour when called. It's not usable as a guard from programming errors, it's just an optimization hint. You still have to write the guard yourself.
Rust has core::hint::unreachable_unchecked, which is an unsafe function that, since we promised never to call it, also promises never to return. This has Undefined Behaviour if you call it, since you formally promised not to (the consequence of unsafely promising something and then going back on it is usually Undefined Behaviour in Rust).
Rust does also have the safe macro core::unreachable which will panic if reached, but while the compiler can assume this probably won't happen and optimise accordingly, it usually can't know that it won't happen (and if it can your decision to add the macro may be unwise)
One reason C++ gets more and more Undefined Behaviour is consistency. The committee will, unless prompted hard not to, draw analogies to existing UB in the language and use that to justify making your new thing Undefined in the tricky cases. The results are pretty embarrassing.
std::unreachable is actually a quite useful optimisation tool. For instance if you are sure that a switch-case default branch is actually unreachable you can put a std::unreachable into the default-branch to hint the compiler that it may remove a range check in front of the switch-case jump table access (since you promised to the compiler that the default branch is never reached).
It's a double edged sword of course. If control flow actually hits the default branch, then all bets are off (because that means the code will access an out-of-range jump table slot and jump somewhere into the wilderness).
AFAIK compilers are free to perform something like Rust's panic when std::unreachable is actually hit, but that makes only sense in debug mode. Because in the above example, the compiler would need to add a range check to figure out if panic needs to be called and that would completely defeat the idea of removing that range check in the first place.
I recommend omitting the default case and putting std::unreachable() outside the switch and omitting the default label for the sole reason that compilers are more likely to warn for a missed case label this way (-Wswitch vs -Wswitch-enum in gcc/clang, the former is included in -Wall, the latter isn't included even in -Wextra).
This also allows expressing intent: no default label means that I meant to handle all cases, and having a default means that I opted into a fallback, please don't warn. That's probably why -Wswitch-enum isn't enabled by default, too many false positives without a convenient way to suppress the warning.
I haven't actually tried that, but if it works as intended it would actually be better yeah (not really in the case where I'm using it, because I'm switching on an integer, not an enum).
switch (e) {
case A:
foo(); break;
case B:
bar(); break;
}
std::unreachable();
instead of:
switch (e) {
case A:
foo(); break;
case B:
bar(); break;
default:
std::unreachable();
}
The former is more likely to produce a warning if there is an enumeration C that you forgot to handle, or you added an enumeration C and missed a switch-case to update.
edit:
duh, it's supposed to be returns here instead of breaks.
Having it available means we can use it explicitly. For example, I could see a compiler flag making `std::vector<T>::operator[]` be checked and then if profiling warrants, remove the check by explicitly checking if my index is out of bounds and invoking UB. Not saying that’s the pattern people will use, but having an escape hatch makes safer-by-default behavior more approachable.
>For instance if you are sure that a switch-case default branch is actually unreachable you can put a std::unreachable into the default-branch to hint the compiler that it may remove a range check in front of the switch-case jump table access
I guess they stole this idea from Terry Davis who implemented this in holyC. When you use square brackets it just doesn't do any range check. Terry, as always, been ahead of the times. Like so:
What I don't get is, why are we still adding more undefined behaviour to the standard?
Because it allows flexibility for compilers to implement features efficiently on various platforms.
You can define undefined behavior if you wish. Make your own unreachable that prints an error and aborts gracefully when reached in debug builds, and calls std::unreachable in release builds.
> What I don't get is, why are we still adding more undefined behaviour to the standard?
Why do you believe this is some kind of problem? Can you explain in concrete terms what issue you have with undefined behavior?
> However, in C++, std::unreachable just invokes undefined behaviour when called.
It does, by design and as a testament to great design choices.
> It's not usable as a guard from programming errors, it's just an optimization hint. You still have to write the guard yourself.
I don't understand what point you tried to make. Nothing in your comment has any relation with undefined behavior. Instead, you're complaining that in your personal opinion different languages have similar-sounding features that work differently.
Oddly, you should really read up on std::unreachable, because one of the reasons explicitly stated in it's references is to "trap them to prevent further execution".
To explain what this means in no ambiguous terms, the standard ensures that a) std::unreachable is valid C++ and made available to the world to have the semantics to specify that a code path is unreachable, and b) allow everyone to handle that as they see fit by flipping flags in the build system.
Think about it for a second. You want to call std::abort when std::unreachable is hit. Great, go with that. I don't, and instead I want the compiler to optimize away that code path and anything it would touch, but on debug builds I want it to output a warning and trigger a breakpoint. Have you noticed that all these cases introduce behavior that's entirely different, arbitrary, and implementation-defined? How do you, as a standards committee, get to cover all possible use cases?
You might be interested in the compiler option -fsanitize=undefined. I think it works for gcc and clang. I don't think it catches all undefined behavior, but it catches some.
On libstdc++ std::unreachable() also reliably crashes if you define either _GLIBCXX_DEBUG or _GLIBCXX_ASSERTIONS. libc++ should have a similar macro. I expect MS STL to also reliably crash on debug builds here, as it's quite heavy on debug assertions in the standard library anyway by default (and debug and release builds are explicitly not ABI compatible there).
And if you ever reach it then maybe the program will crash, or maybe demons will start flying out of your nose. No one really knows, and that's what makes undefined behavior exciting!
It doesn't 'invoke' undefined behavior in the sense that it calls some function 'doRandomShit()'.
What happens is:
Compilers sees unreachable and assumes that this codepath will never run, so it just yeet it out of existence.
For example, maybe it will remove the preceding if-statement and rather then check its condition, just insert true or false. Afterall, why waste computing on checking condition if we know it will never resolve to the unreachable path.
In Rust, the same if-statement won't be optimized away, and if the code happens to go for the unreachable path, it will call panic.
Now, the example is a simplification, but it's just to demonstrate that UB comes from compilers (verry aggressively) assuming UB will never happen, and not because someone decided to "add it".
I recently build some internal app with Qt. Unfortunately, building Qt apps on Windows is somewhat complex.
Also I didn't find a way to install Qt on Windows without later receiving E-Mails from Trolltech (or The Qt Company, nowadays) trying to sell Qt to me.
It's like in the old days before railroads when every town had it's own time, but even worse.