C++ Logo


Advanced search

Re: Remove infinite loop UB

From: David Brown <david_at_[hidden]>
Date: Mon, 11 May 2020 17:35:54 +0200
On 11/05/2020 15:25, connor horman via Std-Proposals wrote:
> On Mon, 11 May 2020 at 03:40, David Brown via Std-Proposals
> <std-proposals_at_[hidden] <mailto:std-proposals_at_[hidden]>>
> wrote:
> On 09/05/2020 15:18, Tony V E via Std-Proposals wrote:
> > The basic idea is a program that looks like:
> >
> > int main()
> > {
> > setupSignalHandlers();
> > for(;;)
> > ;
> > }
> >
> > The real work of the program happens in the signal handlers.
> > Or interrupts. Etc.
> >
> > Nothing happens on the main thread. But it needs to be running for the
> > signal handlers to have somewhere to run.
> >
> > We could have a special function for this:
> >
> > for (;;)
> > std::magic_pretend_im_doing_something();
> >
> > Not sure how we specify it though.
> >
> In gcc and clang, you can use:
> asm volatile ("" ::: );
> It is "volatile", but does absolutely nothing.
> It is standard, of course. But I can't see it being difficult to
> specify.
> I assume you mean non-standard,

Yes, sorry.

> though I suppose the declaration itself
> is standard, just implementation-defined.

"asm" is a common extension, but not standard C++. But at least it is
portable to different processors, which is unusual for inline assembly!

> I don't necessarily like non-standard stuff, especially for high-level,
> abstract stuff like looping. Technically an infinite loop that does
> nothing at all is a valid program for a Universal Turing Machine (of
> which the C++ Abstract Machine should qualify), so this is an entire
> theoretical computing arguement, which I am going to choose to omit.

An infinite loop that has no observable behaviour could be one of two
things in theoretical computing terms. If each run of the loop takes
finite time, then it is a stop - it halts the abstract machine. If each
run takes no time, then you could argue that it /does/ finish, and it
will have done exactly nothing during that time. (You can view this as
the limit of finite loops of increasing size, each doing nothing.)

The C and C++ are specified without any concept of time or timing, only
of ordering of observable behaviour. It is entirely reasonable and
consistent with the way the languages are defined to say that a loop
with no observable behaviour ends after no time - it is also reasonable
and consistent to say that it stops the abstract machine.

> However, what you /really/ want in loops like this is something like:
> while (true) sleep();
> where "sleep" is highly cpu specific. Some cpu's have a "sleep"
> instruction, others have a "wait for events", "halt", "HCF", etc.
> I don't believe all CPUs I target have such an instruction.

That is correct. Pretty much all CPUs of relevance to this century will
have something like this, but there may be some that don't and that are
still practical devices to use. (The 6502 was great in its day, but has
not been relevant this century.)

But the only place where an infinite do-nothing loop could conceivably
be appropriate is deep within implementation-specific coding anyway.

> As far as I
> can tell, the 6502 itself only has STP (65816 does have WAI, so that is
> useful for that case, but I believe it is a New Instruction, so not
> available to older 6502 CPUs), the issues of which I have mentioned
> previously. 6502 would be for NES games, which is a future target of the
> same project that is providing the homebrew platform for SNES Games.
> This should only be used at the lowest level of the system - in the main
> loop of a bare-metal embedded system, or in the idle task of an OS. Any
> other task in a system with an OS should block waiting on some event, or
> at the very least "yield" its time-slice.
> And these sorts of things are all observable events.
> I think the only use I have had for a genuinely empty infinite loop is
> in handling restarts in an embedded system, where the processor is
> twiddling its thumbs waiting for the watchdog to cause a restart.
> Possibly. That would be an example though.

Received on 2020-05-11 10:39:02