What's the intention of printing the value here? This is quite unconventional to return a non-int value in a SystemExit, so maybe this bit can either do nothing, or call mp_obj_print_exception.

But, see also how the unix port handles this: ports/unix/main.c:handle_uncaught_exception. Maybe it's worth copying that code?

It is to keep the behavior consistent with real python:

https://python.readthedocs.io/en/latest/library/exceptions.html#SystemExit

If the value is an integer, it specifies the system exit status (passed to C’s exit() function); if it is None, the exit status is zero; if it has another type (such as a string), the object’s value is printed and the exit status is one.

I know it strictly doesn't have to be and that it is something a little different, but I don't see any reason with not honoring this particular behavior.

Do you want me to change it in some way?

If the value is an integer,

Makes sense, but minor remark: I don't think it is 100% guaranteed (because of different object representations) that mp_obj_is_small_int(val) expresses 'is an integer value' exactly, i.e. there might be integers whos value is larger than what a small int can represent but are still a valid exit code? So perhaps this should try to extract an integer value without forcing it to be a small int?

I believe that a valid exit code is only one byte long anyway, 0 to 255 (sometimes -1, which is equivalent to 255). So I don't think this should be an issue. Is there a case where bigger exit codes might be needed? Can you point to some documentation where they are used? What function do you suggest instead of mp_obj_is_small_int(val) ?

the int is passed to the C exit function.

According to its docs, https://man7.org/linux/man-pages/man3/exit.3.html, only the 0xFF part (the least significant byte, 0-255) is masked and used.

is masked and used.

Those are some version of linux-specific docs so in my understanding they only specify one particular use case 'returned to the parent when using wait'. It's easy enough to find conflicting information which shows the full 32bit can in fact be used both on unix and especially on windows where it's not uncommon; first search result: https://stackoverflow.com/questions/179565/exit-codes-bigger-than-255-possible.

What function do you suggest instead

Hmm, good question. Also depends on whether it should be an actual integer (mp_obj_get_int), or something which can be converted to an integer (mp_obj_get_int_maybe). But in any case another small issue is that those use mp_int_t not int. Probably fine to just cast the result to int though for completeness I'd document that somewhere.

mp_obj_is_small_int should be fine up to 32bits, right? I understand that this is a "pointer-size int". Is it correct?

re mp_obj_get_int_maybe - is there a method/helper, which can check whether it is castable? To run the check before the get and maybe do something else with the object.

mp_obj_is_small_int should be fine up to 32bits, right? I understand that this is a "pointer-size int". Is it correct?

It's stored in a machine word, but it has 1 or 2 bits less available for the actual representation, see mpconfig.h. So not necessarily 32 bits.

re mp_obj_get_int_maybe - is there a method/helper, which can check whether it is castable? To run the check before the get and maybe do something else with the object.

On second thought mp_obj_get_int_maybe should not be used here because it can fall back to calling MP_UNARY_OP_INT_MAYBE which is probably not intended, and I doubt anyone is going to use it anyway. So probably:

if (mp_obj_is_int(val)) {
    val= (int) mp_obj_int_get_truncated(arg);
}

is ok here.

Ok, I applied this and force pushed. Should be ok resolved now.

How does one distinguish between an unhandled exception, and a SystemExit(1)?

One doesn't. That is ok. It is not distinguishable in other programs as well. Only by additional stderr output