During some of my work on mpprint, we discussed the use of flags passed as unsigned. The C standard only requires this type to be 16 bits, and apparently this is actually the case in the pic16bit port.

Unfortunately, the pic16bit port is not even compile-tested during CI because it requires a non-free toolchain. So, I set out to see if there WAS a toolchain that could work that way and might be able to build & run during CI.

Long story short(-ish): m68k gcc with -mshort makes int 16 bits. The linux/libc headers are totally broken in this mode, because they unconditionally typedef unsigned int uint32_t. So, I built my own gcc and newlib-based runtime that can run under qemu-m68k. And some basic things, such as >>> 3+3 (prints 6) actually work!

however I very quickly run into problems. I'm not opening this as an issue because at the moment nobody else could reproduce it, and I'm not convinced it's not a problem in my toolchain. However, I think the problem is in the micropython core.

Here, micropython is trying to print the int type itself, but it's about to crash instead:

(gdb) where
#0  find_qstr (q=0x407ffd74) at ../../py/qstr.c:198
#1  0x800012e8 in qstr_data (q=<optimized out>, len=0x407ffda0) at ../../py/qstr.c:413
#2  0x800020a0 in mp_vprintf (print=0x8001caaa <mp_plat_print>, fmt=0x800246a7 "q'>", 
    args=<optimized out>) at ../../py/mpprint.c:483
#3  0x80002250 in mp_printf (print=0x8001caaa <mp_plat_print>, 
    fmt=0x8002469e "<class '%q'>") at ../../py/mpprint.c:379
#4  0x80015722 in type_print (print=0x8001caaa <mp_plat_print>, 
    self_in=0x800207e0 <mp_type_int>, kind=PRINT_REPR) at ../../py/objtype.c:980
#5  0x8000d844 in mp_obj_print_helper (print=0x8001caaa <mp_plat_print>, 
    o_in=0x800207e0 <mp_type_int>, kind=PRINT_REPR) at ../../py/obj.c:129
[snipped]
(gdb) frame 0
#0  find_qstr (q=0x407ffd74) at ../../py/qstr.c:198
198	    assert(*q < pool->len);
(gdb) p/x *q
$25 = 0x5e3faf
(gdb) frame 4
#4  0x80015722 in type_print (print=0x8001caaa <mp_plat_print>, 
    self_in=0x800207e0 <mp_type_int>, kind=PRINT_REPR) at ../../py/objtype.c:980
980	    mp_printf(print, "<class '%q'>", self->name);
(gdb) p/x self->name
$26 = 0x5e

In type_print, self->name is of type unsigned short. A short is promoted to int (also 16 bits) and then it becomes part of the ... args in mp_vprintf.

In mp_vprintf, an argument is retrieved with qstr qst = va_arg(args, qstr); but qstr is size_t, a 32-bit type.

This is undefined behavior, but the concrete behavior here is that it got back a 32-bit value that combines the correct value (0x5e in the high bits) with some unrelated values from the stack (0x3faf in this case).

Upon continuing, an assertion error occurs:

<class 'Assertion '*q < pool->len' failed, at file ../../py/qstr.c:198

So I'm asking myself "how did this ever work" but with a side helping of "wait, how do LP64 platforms work" because again sizeof(size_t) will be different than sizeof(int).

I went and wrote a godbolt.. https://godbolt.org/z/nrj6xa8er

#include <stdio.h>
#include <stdarg.h>

void fn(int i, ...) {
    va_list ap;
    va_start(ap, i);
    while(i--) {
        size_t v = va_arg(ap, size_t);
        printf("%zx ", v);
    }
    printf("\n");
}
int main() {
    fn(8, 1, 2, 3, 4, 5, 6, 7, 8);
}

with x64 msvc v19.43, this prints

1 2 3 7ff700000004 7ff700000005 6 7 8 

so it "works, kinda, sometimes, maybe due to luck". I have a sinking feeling that if there were a printf with 4 %q arguments it might just fail on x64 windows.