I think this is an interesting case study in how it's difficult to anticipate the needs of the future and not over-engineer a protocol at the same time.
Accesses to volatile objects and calls to library I/O functions are observable behavior. The implementation may perform any transformation of a program, provided that the resulting program’s observable behavior is not changed.
So it seems that running forever isn't an observable property that must be preserved when code is transformed.
Still, I think compilers try to not surprise the developer too badly and would recognize a trivial loop most of the time.
The lovely part about UB is it’s non-causal. The compiler can go back in time and steal Halloween candy from you when you were five and still comply with the specification.
Yes, that's the one! Famously buddies with Epstein and credibly accused of sexual assault of children on several occasions. Convicted felon Trump, the very same.
Uh, she has no experience as a prosecutor before this. Of course she has no clue how to operate legally. She was never qualified in the first place. Her role was as a pawn to prosecute enemies of king Trump and providing for her convenient disposal as a used napkin when she outlives her usefulness to the king.
The compiler (in C) is allowed to assume that infinite loops eventually terminate. This can lead to these kinds of loops not actually running forever when built with an optimizing compiler.
“An iteration statement may be assumed by the implementation to terminate if its controlling expression is not a constant expression, and none of the following operations are performed in its body, controlling expression or (in the case of a for statement) its expression-3: – input/output operations – accessing a volatile object – synchronization or atomic operations."
It can, for example, simply optimize it away, assuming non-productive infinite loops are stupid and not reflective of what the code will actually do.
It really is such a cool concept. The autism in me hates the name though because there's always a server. I wish it were called a "container-based service" or even just "containers" instead of serverless to be more direct. Perhaps even "web functions."
There's so much big talk about scale but really, scaling is not that important to 99% of businesses I've worked at. You're not a startup. Your typical server has a huge amount of resources if managed appropriately. I guarantee and would bet money that you'll never have a million users let alone a billion using your medical coding web app. Like, sit down!
I aspire to one day be as knowledgeable and well-rounded in computing as he.