On Sun, May 10, 2020 at 19:04 Jason McKesson via Std-Proposals <
std-proposals_at_[hidden]> wrote:

> On Sun, May 10, 2020 at 3:43 PM connor horman via Std-Proposals
> <std-proposals_at_[hidden]> wrote:
> >
> > This would depend on the implementation of the VBLANK.
> > I usually want to redraw the screen even if nothing changed.
>
> Again, stop me if I'm wrong, but my understanding is that if your
> VBlank routine doesn't do anything at all, doesn't touch CGRAM, VRAM,
> OAM, or any PPU registers, the PPU will automatically render in accord
> with what you had previously defined. AKA: it will "redraw the
> screen".
>
> If that's the case, I'm not sure I understand why a VBlank routine
> could not be coded to simply return when the program has reached a
> terminal condition.

Possibly.
If I'm doing slightly more interesting stuff (but stuff that needs to be
done from VBlank, or possibly HBlank IRQ), like maybe spinning the mode 7
screen, or doing some HDMA (for maybe a shaking effect), nothing really
would need to be done in the main thread, but spin, waiting for either an
IRQ or NMI.

>
>
> > Also, I'd add that apparently C does not have/no longer has this
> issue(at least by C11, see
> > http://port70.net/~nsz/c/c11/n1570.html#6.8.5p6). Where the loop
> condition of a for loop is a constant expression (empty conditions are
> included), the loop cannot be assumed to terminate. I can't see much of a
> reason for this to be different between the two languages.
>
> I did some light research, and I found that C and C++ apparently
> decided on different ways of dealing with the same issue. That issue
> being that non-terminating code should be considered UB. See
> http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1528.htm for details.
>
> The C11 approach only made it UB in a specific case: explicit looping
> constructs. The WG14 N1528 paper doesn't cover `goto`-based infinite
> loops, nor does it cover infinite tail recursion or other forms of
> infinite looping.
>
> By contrast, C++11 wording is a blanket statement of *visible* forward
> progress. It doesn't care about the specific way you might fail to
> achieve visible forward progress. It doesn't care about whether the
> loop uses a constant expression or not. All that matters to the C++
> wording is whether the code does anything that can be seen either from
> another thread or from outside of the system.
>
> So if anything, C++'s wording is better than C's wording. It certainly
> covers the bases more.

Though that leaves room for a lower level language, C or even Rust (which
also has a valid infinite looping construct loop{}, which the fact it is
infinite is relied upon for soundness).

I would argue that where a user intends to invoke an infinite loop, and
that intention is clearly communicated (condition of for/while/do-while is
either a contextually converted constant expression of type bool, which
after conversions evaluates to true, or the condition of for is omitted),
the construct should be permitted. It harms embedded use cases (what about
processors that don't have a STP instruction); can be surprising for people
coming into C++ from other languages that do have endless looping
constructs, including C; and even serves to limit the common subset between
languages further.

>
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals

<https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals>


>