Fix compilation warning about unreachable code

[ar-cetitec]

All paths inside the endless loop (while (1)) end in a return, but the function contained another return 0 at the end of the body, which was never reached.

Use the EOF path (which returns a 0) inside the loop to jump to that return 0.

[axel-h]

avoid warning about the function not returning a value.

May reword the commit comment to be clear what error is we are avoiding. The last statement is unreachable, so getting this as warning is understandable. But all code paths that return, do also return a value. So, where do you get the error that it's not returning a value?

[ar-cetitec]

avoid warning about the function not returning a value. So, where do you get the error that it's not returning a value?

If I remove the final return (just that, without introducing the "break").

To be fair, I cannot find a compiler, which would not see that there is no way out of loop except for those "return" statements inside it.

Almost all compilers on godbolt.org don't complain about anything in any case (TCC complains about the unreachable final return), so that's another option: just remove that last line.

That particular build environment, which complains about the unreachable code (GreenHills C compiler 201955), does not complain about anything if I remove the final "return 0". I didn't do exhaustive check with all possible warning levels though (it's cumbersome: there is no simple way to activate all warnings, you really have to try obscure command-line options out).

[ar-cetitec]

Updated commit description to better match common commit style in the repository.

[kent-mcleod]

Which compiler version was generating a warning about unreachable code?

[ar-cetitec]

Which compiler version was generating a warning about unreachable code?

GreenHills C/C++ compiler, version 201955 for Renesas RH850 processors, non-MISRA mode.

[kent-mcleod]

Thanks for taking the time to make a PR! Are you trying to run seL4 on a RH850 processor? Feel free to send me a message if you run into any issues.

[ar-cetitec]

Thanks for taking the time to make a PR! Are you trying to run seL4 on a RH850 processor? Feel free to send me a message if you run into any issues.

Unfortunately, no, it's bare metal. We don't have the development capacity for seL4 :) It is just the util_libs, and on behalf of my team I would like to thank seL4 project for concise code!

[ar-cetitec]

Thanks for taking the time to make a PR! Are you trying to run seL4 on a RH850 processor? Feel free to send me a message if you run into any issues.

Unfortunately, no, it's bare metal. We don't have the development capacity for seL4 :)

That said... Are there absolute minimal hardware requirements for the kernel somewhere?

[kent-mcleod]

Unfortunately, no, it's bare metal. We don't have the development capacity for seL4 :) It is just the util_libs, and on behalf of my team I would like to thank seL4 project for concise code!

Ah interesting to know!

That said... Are there absolute minimal hardware requirements for the kernel somewhere?

Currently a MMU is required which excludes most micro-controllers. While in theory it's possible to achieve similar capability enforced resource isolation using only an MPU, this hasn't been attempted with seL4 in practice yet.

[ar-cetitec]

That said... Are there absolute minimal hardware requirements for the kernel somewhere?

Currently a MMU is required which excludes most micro-controllers. While in theory it's possible to achieve similar capability enforced resource isolation using only an MPU, this hasn't been attempted with seL4 in practice yet.

Renesas RH850 (an V850 variant). MPU only, unfortunately.