> The question here is: can the compiler hoist the final division operation above assignment to x?

A division calculation not a visible effect. Therefore the question doesn't even m ake sense: it's asking: can we see something that is not a visible effect (division) before or after a visible effect (modification of a volatile object).

But a division that traps because you divide by zero would prevent previous observable behavior from happening when hoisted above it. So it is not about the division itself but about the indirect effect on other behavior that can be observed.

Compilers already understand this: For example, they would not hoist a potentially trapping operation such as a division above a function call. The issue is that they did not apply this rule also to volatile accesses, but LLVM now does because this was fixed.

but "previous observable behavior" just means whatever actually happened, not that it was required to be previous.

I do not understand what you mean by "whatever actually happened". The point is that before compilers were fixed previous volatile stores were not safe from compiler optimizations (GCC still has this bug, but now fixed on LLVM) or that even previous function calls were not safe (fixed in MSVC and GCC).

What if x is a register to toggle divide-by-zero exceptions? Normally this is none of the compilers business, but the whole point of volatile is a mechanism to express stuff like that, so it needs minimal semantics, e.g. no time traveling (compiler barrier), to be fit for purpose.

x being a register connected to the processor's division machinery doesn't speak to the fact that division isn't a language-defined visible effect, and so the implementation is not required to schedule it in a certain way in relation to the store to x.

Hmmmmm. It's late, but FWIW I think this comment from Martin from last year might be relevant: https://news.ycombinator.com/item?id=40838721 And I'm guessing the note that was added is fn#150 in C23. Volatile accesses aren't general memory barriers, but I think Martin's point is the potential for UB behavior means the compiler has to preserve the sequence order of the potentially UB operation relative to the volatile access.

That is conscious; the page references oracle bone script / seals as being close to their concept, and kamon as being even closer.

I don't think you can drop the word "mon" into a conversation and be readily understood without additional explanation; what you want is "monshō" (紋章) to talk about heralds in general.

I had an automatic Micra (2016). It was a gas guzzler in the city, striking at 10l/100km at times. When shopping for a car to replace it, I did check out the 5 speed manual version. That stupidly asks you to rev 3000 RPM in 5th gear at 100 km/h. There is a 6th gear missing there, or a taller fifth: oops, fail! And they thought that someone who wants a manual car won't be needing air conditioning or power windows, etc. the idiotic, outdated thinking that the manual transmission is just an ingredient in making the cheapest possible version of the car, and not somehing that is a special feature to the enthusiast. Double fail ...

Manual 2005 micra which I drove until last January was reliably 6.3l/100km. No aircon but did have electric windows. And a cd player.

Manual skoda kamiq which I drove until May was about 6l/100km

Those are real “how many miles did I drive, how many litres did I put in to fill the tank” figuresc although tend not to do a lot of inner city driving - because that’s what public transports for.

The number one goal for AI labs is obviously their self-preservation, by any means.

I had a membership since 1994. They basically erased it.

Between that, and selling out to a foreign-private-equity-held holding, and the incident during which an innocent shopper who came to return an item was attacked by a security guard, and the idiotic Vancouver location with no connection between underground parking and the store room, I decided never to set foot there again.

Fuck MEC, the Mountain Equipment Coo^H^Hompany! Not the MEC you knew.

Actually, I should mention that I didn't know about their corporate change from a co-op with members. My first contact with the change was my account being erased and being told to create a new one because they are "changing over to a new system". No mention of having become a different, scummy company. Basically they started out by lying to long-time customers of the old MEC that it was just their database that was changing and for some inexplicable reason, not being able to migrate the old membership accounts. Just despicable.

It didn't. The battery killed itself. Modern rechargeable batteries don't like being left discharged in storage.

In what way is it not a process restart if I stop the process, install/upgrade NeoVim and start a new process?

It's the part where you upgraded and apparently failed to read the release notes.

Or in the OPs case, installed a totally different application and was surprised by an incompatibility.

Nobody should have to read release notes to avoid data loss; there should never be a change such that someone who hasn't read the release notes (or missed a detail in reading them) to avoid such a problem.

You're holding others to a standard that you yourself haven't adhered to. Please go read the release notes. No mention anywhere that old undo data will be deleted.

https://neovim.io/news/2021/07/

Differences from Vim are also documented, but this issue isn't mentioned there either.

https://neovim.io/doc/user/vim_diff/

Also, what's up with people claiming that the undo files are stored under ~/.cache? That's completely made up. Or that persistent undo doesn't persist edit history, against what the docs say. Utter nonsense.

https://neovim.io/doc/user/undo/#_5.-undo-persistence

Users don't expect their editor to cause data loss after a routine `brew update`. Blaming users for that is unreasonable.

That doesn't work here because the data was not wiped by a generic cache flush from a third party script or whatever, but a targeted hit from the application itself on files known to be persistent undo.

You just can't point the finger at file system standards, or shoulda-read-release notes or whatever.

There is no such thing as "by mistake, we historically stored persistent files in a directory with 'cache' in its name, contrary to a popular standard, so that makes it okay to trash them now".

> That doesn't work here because the data was not wiped by a generic cache flush from a third party script or whatever

But it was, it was program other than vim (neovim) that did it. It deleted a file in a space that is meant for transient files that may be deleted at any time for any given reason and should not cause data loss, and yet it did because vim, in the first place, broke the file system’s contract.

Neovim shouldn’t have been messing there but at the same time there’s a much bigger culprit here in that vim shouldn’t have been storing this kind of data there in the first place. It was a broken system that broke even further. Simple as that.

NeoVim is a forked continuation of Vim.

Blaming Vim is like politicians blaming the previous administration.

> The application must be able to restore or regenerate the data

That's a break of the contract then, right? The application was not able to regenerate or restore.

Cache is the wrong place for a persistent undo file.

I was without a car for half a year 2026-02 to 2026-08 and drove a number of electrics from the local car share (where I've had a membership since around 2011). Hyudai Kona, Kia Niro, Chevy Bolt, ...

I had a good camping experience with the Niro. Since Kia doesn't believe in spare tires being default, I was able to stuff sleeping bags, beds and a bunch of other stuff all underneath the hatchback floor, in all that secret space, leaving a ton of room above for everything else.

I like the acceleration and quiet/clean operation of electrics, but in the end I got a 6 speed manual.

Electrics are super dangerous; they accelerate like souped-up competitive track cars. They really need to tone that down: use much smaller motors with less torque, and hack the software to cap the acceleration.

I'm a much calmer driver in a manual. I'm driving for fuel economy, so I'm always in a gear where I have no power. (And in a 6 speed that has about the range of a 5 speed, there is always a good gear to be in at city speeds, where you are at between 1500-1800 RPM). So, I cannot just step on the accelerator on a whim because that will usually do nothing. There is an activation energy for speeding up, due to the chore of shifting down, which discourages doing it casually. In an electric it's like, oh, I suddenly see this opportunity, and blam: you're on the accelerator and the distance between here and there is erased faster than you can hit backspace.

> Electrics are super dangerous; they accelerate like souped-up competitive track cars. They really need to tone that down: use much smaller motors with less torque, and hack the software to cap the acceleration.

My ID.3 has three "performance modes": Eco, Comfort, and Sport. You only get the souped-up acceleration if you tell it to go into "Sport" mode.

After 2 years of Tesla ownership I got s3xy commander which hacks into CAN. It has kickdown feature where it goes from chill into standard mode if you bottom out accelerator. My Tesla isn't even that fast (technically slowest after semi) and I thought I'm good at controlling accelerator, but I've been using this kickdown mode for a while now instead...

At one point my car had a firmware update that made the Eco mode sluggish in acceleration. I thought it made perfect sense; being economical in battery use means limiting acceleration. It received so much backlash that the manufacturer had to issue a subsequent update to increase the acceleration cap.

Why don't the idjits just offer two levels of "Eco"?

Maybe people like the regular Eco mode for reasons other than economy; like they use it as a kind of one-pedal driving, since it offers regenerative braking when you back off the accelerator.

There needs to be a mode for those drivers, and a mode for those who are serious about maximizing battery run times.

Fighting and backlashing over mere software configurations of one thing is so senseless.

Kia Niro is where the Koreans have invested their stuipd; a stateful panel in which volume and temperature knobs are multiplexed, and and so are tactile-free touch places on the panel between them. And it won't stay in the same mode; it changes it behind your back. You think the knob is volume because you last tweaked it a minute ago, but nope, you are messing with the temperature now.

The good news is this ought to change in upcoming models, because the EU safety rating now requires physical knobs for a bunch of those controls