Author here. I believe it's kept because at the end of the day, they _must_ get a valid value form it; however, the chances of that loop having to run more than once are astronomically low.
I understand that, but an infinite loop is not a valid response to a program's preconditions being unfulfilled.
The infinite loop is a landmine left in the field.
Handling the negative -1 with a log error and an assert, would be better than an infinite loop.
Infinite loops can damage even other programs by hogging the cpu. They are far worse than an exception or an std::exit.
I think in the authors example, having sway fail to parse JSON would have been a better fallback than having the entire system lock up.
I don't want to be over dramatic but leaving that infinite loop in there is the type of mindset that leads to horrendous code bases decades from now.
Sway and Wayland was created to get away from the warts of X11. This infinite loop is bringing the new effort closer in line with its ugly older cousin.
To be clear, this loop doesn't exist in Sway proper: it lives in json-c, a third-party library used by a lot more than just Sway. A lockup bug was reported to a lot of projects using json-c at the same time.
This really wasn't a Sway/Wayland thing, we just happened to be the first to diagnose and contribute a fix upstream.
The infinite loop is a landmine left in the field.
Handling the negative -1 with a log error and an assert, would be better than an infinite loop.
Infinite loops can damage even other programs by hogging the cpu. They are far worse than an exception or an std::exit.
I think in the authors example, having sway fail to parse JSON would have been a better fallback than having the entire system lock up.
I don't want to be over dramatic but leaving that infinite loop in there is the type of mindset that leads to horrendous code bases decades from now.
Sway and Wayland was created to get away from the warts of X11. This infinite loop is bringing the new effort closer in line with its ugly older cousin.