No, because the former definition is still something you can rely on given a specific compiler and a specific machine. Hell a bunch of UB was pretty much universal anyway. Compilers would usually still emit sensible code for UB.
UB just ment "the spec doesn't define what happens". It didn't use to mean "the compiler can just decide to do any wild thing if your program touches UB anywhere at anytime". Hell, with the modern definition UB can aparantly time travel. you don't even need to execute UB code for it to start doing weird shit in some cases.
UB went from "whatever happens when your compiler/hardware runs this is what happens" to "Once a program contains UB the compiler doesn't need to conform to the rest of the spec anymore."
>the former definition is still something you can rely on given a specific compiler and a specific machine.
>UB just ment "the spec doesn't define what happens"
What comes to mind is that then the written code is operating on a subspec, one that is probably undocumented and maybe even unintended by the specifics of that version and platform.
It sounds like it could create a ton of issues, from code that can’t be ported to difficulty in other person grokking the undocumented behavior that is being used.
In this regard, as someone that could potentially inherit this code I’d actually want the compiler to stop this potential behavior. Am I missing something? Is the spec not functional enough on its own to rely just on that?
int handle_untrusted_numbers(int a, int b) {
if (a < 0) return ERROR_EXPECTED_NON_NEGATIVE;
if (b < 0) return ERROR_EXPECTED_NON_NEGATIVE;
int sum = a + b;
if (sum < 0) {
return ERROR_INTEGER_OVERFLOW;
}
return do_something_important_with(sum);
}
Every computer you will ever use has two's complement for signed integers, and the standard recently recognized and codified this fact. However, the UB fanatics (heretics) insisted that not allowing signed overflow is an important opportunity for optimizations, so that last if-statement can be deleted by the compiler and your code quietly doesn't check for overflow any more.
There are plenty more examples, but I think this is one of the simplest.
It should be mentioned that as far as I can tell pretty much no one is selling pure PLA filament. They all have additives, so who knows what the actual glass transition temperature is for any random given filament. This has been true for a while too. Pure PLA has some properly awful properties, among which is it having pretty much no elastic deformation. Any amount of force will introduce microscopic cracks. The various additives reduce these kinds of issues and are therefore not really optional.
Roughly no one already says GSM. When talking about paper you'll hear people say things like "That's a sheet of 120 gram"
GSM basically only ever appears in print. If someone DOES ask "what does 120 gram mean here?" the clarification is going to be "Oh that's grams per square meter" and not "Oh that's gee es em"
I should mention GSM is also probably an americanism. I'm in the EU and out of the five packs of different kinds of art paper four are labeled in g/m2, and one has no labeled weight at all. None of them are marked in GSM as that abbreviation only works in english, while g/m2 works in all languages.
In the UK, "gee es em" was the usual term I heard at the local paper merchants when I was a regular customer in the late 90s - early 2000s.
Of the four reams of paper/card I have at home, two are labelled in "gsm", one is "g.m⁻²", and one uses both "g/m²" and "gsm" in different places. Weirdly, it seems that the specialist stuff is more likely to use "gsm" than the everyday 80 g/m² A4.
> Doing anything usually involves prep work. Want to take a step? First put on your shoes (literally or figuratively, depending). If your attempted habit is 70% prep, your brain will somewhat rightfully conclude "this is stupid" fairly quickly.
Note that this is also something that can be weaponized. Recently I've learned to draw and I found I kept having great difficulty just starting. To get over that I made the agreement with myself that at least once every two days, I would grab a pencil and page through my sketchbook. I'd find myself on the first blank page holding a pencil.
Turns out your brain thinking prep work without actual work is stupid really helps here. Once you've tricked yourself into doing the prep work, you might as well do the work-work.
e.g. for distance running: just make the deal with yourself that putting on your running clothes/shoes/etc and taking one step outside counts as having ran that day. You'll find yourself going for a run anyways once you get outside, because you might as well.
> "Just do X every day for [long time period]" has an inherent falsification problem
Very true, but unfortunately a lot of things worth doing require that sort of investment. When learning to draw I hated every single second for the first ~two months or so. And then like a switch getting flipped I started having fun.
> You can actually make steps so small that they're useless.
You should take the biggest steps you can actually keep yourself to. Maybe that leads to steps that are sub-optimally small, but taking useless steps is still doing more than taking no steps.
> Doing something daily for a long time is extremely hard to achieve
Oh for real, especially once you factor in force majeure. Hence why I went with "draw at least once every two days". That gives you wiggle room to plan around life events.
Turns out building habits is incredibly hard and no amount of seeking advise will do it for you. It's a slog and you gotta overcome that yourself one way or another.
It's probably illegal. It's not wrong though. I'm not generally a fan of vigilante justice, but with the rise of fascism lately it's better to act sooner than later.
The trick there is that when everyone else is drinking they'll be making huge social gaffes almost continually. Makes it much easier (for me at least) to relax and not worry so much.
UB just ment "the spec doesn't define what happens". It didn't use to mean "the compiler can just decide to do any wild thing if your program touches UB anywhere at anytime". Hell, with the modern definition UB can aparantly time travel. you don't even need to execute UB code for it to start doing weird shit in some cases.
UB went from "whatever happens when your compiler/hardware runs this is what happens" to "Once a program contains UB the compiler doesn't need to conform to the rest of the spec anymore."
reply