The only reason I clicked on the link was to read a list of examples, but for some reason the author seems to really want to define what a situationship is instead, disappointing
I worked on Internet Explorer implementing part of the SVG spec. There was one case where the spec said one thing and the other browser vendors did something different, so I got buy-in to declare the spec as incorrect and matched the prevailing behavior.
> Metadata is open-world positive evidence; missing facts do not prove SQL invalid. Numeric exactness, JSON/temporal profiles, and nested containers remain separate evidence boundaries.
Fair, but does that mean that the entire article is speculative? They were not around long enough to confirm whether or not it happened for days, but the fact that the mother stayed for at least some hours appears to be confirmed (although as another reply said, the motivation for staying could be different than ours).
You will likely find a lot of these hedging comments in scientific articles, as it’s hard to know and prove something with 100% certainty and it’s an important task for researchers to also indicate the limits of what they’ve discovered. I think ;)
> They were not around long enough to confirm whether or not it happened for days
And that is perfectly fair. But what is the “possibly days” based on? Did they see the two whales acting weirdly a day later, but then they didn’t see them four days later? Or is it just based on the hunch of the person who made the observation? Or is it the hunch of the researcher? And if it is a hunch is it based on knowledge of similar reported events in the past? Is it based on the observed state of the adult whale or maybe the state of the carcas?
Why possibly days and not possibly weeks?
> but the fact that the mother stayed for at least some hours appears to be confirmed
Is it confirmed? So that’s the problem. The hours are comming from the same sentence which describes the days. Both by a person who did not whitness the event personally. Your reading is that the second part of the sentence (the days) is speculation, while the first is reporting on observed fact. My reading is that the journalist did a bad job separating the first hand observed facts from the second hand speculation. We just simply won’t know until someone asks the Captain what exactly they have seen and writes it down.
> it’s hard to know and prove something with 100% certainty
But it is not hard to describe what was observed, and clearly separate it from what they think or speculate. Also it is not hard to ask the person who actually did the observing to describe what they have seen, instead of it being described by someone else who was not present.
You are correct. The underlying scientific article is clear on the timeline of observations. My problem is with the editing done by the phys.org article.
Well you leave the C++ realm (execution model), as you should with UB and it depends on implementation. The implementation of the compiler was such that the two functions are placed after each other in the machine code; and if the first function doesn't return, then you continue executing into the code for the next function.
But the compiler assumes the function will make forward progress. If the function does that, it will return, so why doesn’t the compiler emit a function epilogue?
Because there is an infinite loop that makes the epilogue unreachable, so it is safe for the compiler to remove it!
Sure, that optimization interacts badly with the optimization that removes the infinite loop. But half the point of UB is to avoid needing to deal with such interactions, because they are defined out of existence.
The compiler can assume that the function will return, but it can also statically deduce that the function cannot return. That's a contradiction, so the compiler deduces that the function is simply UB when called, i.e. no need to emit an epilogue. It's the logical principle of explosion in compiler format, basically.
the 2nd call might happen internally due to branch prediction but in practice it shouldn't and the processor fixes this
Oh yeah and TFA also goes with:
> The funny bit is that C got this right.(...) but C included one more rule: loops whose controlling expression is a constant expression may not be assumed to terminate.
Well, duh! A broken clock is right twice a day it seems
I'm also confused that an uncalled function is even compiled and linked, wouldn't it make sense to remove it entirely if the compiler can detect that it's never called?
If it's declared as static, maybe (well, usually, in my experience. You'll also usually get an unused warning). Otherwise the compiler can't assume some other compilation unit won't want it. Linkers can perform a garbage collection pass but they don't often do it by default and they often need finer grained information from the compiler (see the gcc arguments --ffunction-sections and -Wl,--gc-sections)
I can understand adding the 'unreachable' function to the object file, I can even understand plugging it into the final executable, what I (and most other people) object to is making it the de-facto entry point.
This is literally the opposite behaviour compared to what is written in the source code, even when you "assume the infinite loop terminates".
That's the problem with UB, once you hit it (or even have it in your code), you can't really trust anything about the execution anymore. That the function is called isn't something the compiler does on purpose, it's just that the main function is compiled empty due to the UB and the function directly behind it is executed because the CPU just keeps looking for the next instruction.
The assembly gives a bit of a hint as to what's happening.
main:
unreachable():
push rbx
...
Due to the undefined behavior, it decides calling main must be impossible, so the easiest thing to do is just give up, don't bother defining the rest of it. You can also do the same with std::unreachable(). But the label for the function still sticks around for some reason, so when you jump to it, it falls through. Which leads to the really stupid fact that reordering the functions changes the behavior.
I assume there are good reasons they can't just completely delete the label. Maybe it would screw linking, or with cases where you deliberately have multiple labels for the same function. And if the effect is only visible due to undefined behavior, it's not technically wrong. But I have always thought this is such a stupid case, surely it can't be that complex to add a trap instruction, even in an optimized build you shouldn't really care if it slows down a function that's "never called".
I suspect it's more a chain of: emitting the ret is unnecessary because the infinite loop will never return -> emitting the infinite loop is unnecessary because there's no side effects within it and it's undefined behaviour -> emitting any setup for the function is necessary because it's doing nothing else (all probably decisions from different stages of the compiler).
The CPU doesn't really see functions, it just sees instructions. Functions are a convention on top of the machine code. What happens in this case is the compiler emits essentially a malformed function: it ends without performing a return, so execution just continues into the next function in memory. You can get the same behaviour by missing a 'return' statement from a function that needs one (though in that case I've also seen kind of the opposite: the function returns into the function two slots up in the stack, essentially returning from the function that called it! Undefined behaviour can utterly destroy normal control flow).
Probably the process was one optimization pass saw that the function will never return due to an infinite loop, and removed the function return from the IR of the function, then a later pass saw that the infinite loop was a no-op and undefined so removed that as well, leaving a function that basically did nothing, not even return.
> The CPU doesn't really see functions, it just sees instructions. Functions are a convention on top of the machine code.
Not really true, most instructions set have instructions specifically to implement functions as found in normal programming languages. x86 has CALL and RET for example.
they have instructions for implementing them, but the important point here is that functions are still only defined by instructions that are executing between a call and ret instruction (or their equivalent more spelled-out equivalent operations), and not only can these not match up with what the compiler considers a function (for useful reasons like tail-calls as well as not-useful reasons like compiler bugs and UB), it might not be statically obvious exactly what instructions these are. So the CPU in practice has only a rough guess of where the function boundaries are (it might use these guesses for things like branch prediction, but they don't define the visible execution of the code beyond the nuts and bolts of what those instructions actually do).
reply