So my simple resolution has become: don't rebase anything beyond trivial. I use rebase -i to merge, delete, or reorder individual commits on an insolated feature branch. Anything else? Not worth the effort in my opinion. Just merge, in any direction. I even merge between feature branches sometimes, though one must be aware that this essentially glues the two feature branches, meaning either both or none can get merged to master.

Something worth stressing: The most important commit is always the one HEAD points to. Older commits don't matter so much to the degree that cleaning them up later is wasted time. The most value of git commit graph comes as a support structure for git merge. In most cases, nobody gives a shit that all intermediate commits are perfect for some definition of "perfect". Most commits will never be read again.

With rseq, we can allocate in any userland process one instance of a given synchronisation data structure per each CPU. It's important to understand that userland code accessing per-cpu data structures cannot prevent being scheduled away from a CPU and being replaced by another thread (kernel code can block scheduler for short critical sections). Such a replacement thread may subsequently corrupt that same data that was still in the middle of the transaction. But we can make a subset of transactions safe at least: If a transaction gets committed in a single (final) atomic instruction, and we get kernel support for this transaction to be restarted in case there has been a schedule mid-way, this is a guarantee that at the time of commit, the entire transaction hasn't been interrupted by the scheduler. I.e. a kind of "mutual exclusion" guarantee.

Did I get that right?

You keep posting about obscure products like whatever UML Editor that noone cares about, why would I listen to what they say, and why do you not even link anything to look up?

I'm saying that most of features like templates, constexpr, reflection etc. don't scale well to serious use, as a broad statement. I fully acknowledge this is not a black and white situation. But I encourage you to look at actual pedestrian code, it's mostly not abstracted fluffy magic template code at all. It's pushing individual bytes with totally basic means (mostly C code). Why? Because code using these fluffy features is terribly hard to maintain. Templates lock you in their own language world with incredibly bad syntax and bad ergonomics, in short: it's a pain!

Personally I think even C++ classes (i.e. 1980's C++) are unusable because they bifurcate syntax/semantics needlessly and add implicit invisible scope. But I acknowledge it's somewhat possible to program with classes, and some people like to lean on RAII heavily. I mostly do not like to use RAII, and I've tried many times, I think it sucks for non-toy programming, even though obviously the idea is intuitive.

Reflection has always been a mess no matter which implementation or language I've used. Fine for scripting languages, unusable for anything serious complex. The data you need is never there, and the data that is there is unusable, at the wrong semantic level (programming language level not what actually your own domain model semantics).

Also I avoid templates for the same reason, they're quickly becoming unmaintainable. Yes, I've tried to make use of them many times, and I have a fair number of them in deployed software. They work without bugs, of course. But I still don't love them, they're boilerplatey hard to maintain complexity that would be better solved with the right factoring plus a tiny bit of ad-hoc boilerplate. I would like to remove many of my deployed templates if I had the time.

And yes, I even avoid std:: template containers and such. Most uses I regret later. Again, this is for systems programming. They're fine for "scripting", leetcode, business software.

I am talking about self-inflicted complexity that is entirely within the C(++) machine model. Avoid that complexity and you're pretty good already. Only drop down to concrete hardware arch level where it makes sense. But largely, the C machine model is still very much suited as a model for actual hardware. Writing straightforward obvious code allows you to stay in control of memory layout and the data transformation paths. It easily gets you within <<2x of what you could achieve with hand coded assembler for the >90% of the code that are pretty boring and straightforward. And obviously you couldn't get the work done in time when coding everything in assembler.

So it's all about understanding and control, not about some idea that C was defined in terms of assembly instructions, which it obviously is not. That's a total strawman.

But anyway, you're complaining that you have to work too hard to do unaligned loads (i.e. the wrong thing even if it should work on a particular machine) in C, when basically every other language makes you work more for basic systems programming tasks?

Whether unaligned loads can work on the machine level, it depends on the hardware. On some other architectures, you probably get anything from traps to unpredictable behaviour. It's totally fine that C does not define the behaviour for unaligned loads.

If you want to do some weird stuff like loading a single unaligned 16 byte quantity, where there was no "middle part" to begin with, just do memcpy then. The compiler might just do the appropriate thing on this architecture. Or if you need to closely control what's happened, write assembly then. But again, why would you even do this?

Or tell me how you write a Rust program differently given that signed overflow is apparently defined? I bet you write it exactly the same way, and you get pretty much the same behaviour in practice. And we're even only debating actual overflow situations, meaning there is a bug whatever the compiled behaviour is.

C the language doesn't even guarantee that the machine has native integers with 8, 16, 32, 64 bits etc, that a cacheline is 64 bits, that a page is 4K, and here I am, writing programs for exactly that.

Now are there many cases of UB in C, many more than strictly need to exist on contemporary platforms? For sure there are. But does it affect me? Not unless I need a specific behaviour common to most contemporary platforms that I can't get within the confines of C, even considering compiler specific extensions. Honestly I can't come up with any of the top of my head. Maybe some integer-shifting stuff or such, if the compiler was able to prove I'm doing sth undefined, it can leave out that code (or delete my mail, for the doomers). Personally, it hasn't happened to me, and it's on the compiler authors to not do stupid things too.

Leaving all the semantic hair-splitting aside. What is the practical difference in how you write a Rust program compared to a C program, given that integer overflow is "defined" in Rust?

It did. The compiler added the checks (which panic on overflow, from a quick web search) precisely so it (and importantly, the developer!) can assume the overflow didn't happen in the subsequent code. Unless you consider a panic a defined state, and consider wrap-on-overflow equally valid in all cases, it's essentially the same as UB. (panic seems to be considered "unrecoverable").

Difference is _at most_ that C spec gives compiler more freedom to "implement UB", but then again, hit any unsafe code in Rust with wrapped around integer, you probably have comparable practical result -- machine doing random things, corrupting memory and so on.