ssize_t-problem-context

<heat> geist, the ssize_t printing one
<geist> oh all of them? yeah. i usually build with WERROR locally, so i already see one in dlmalloc
<geist> oooh should probalby add a -u flag to scripts/buildall
<heat> well, I meant the one introduced by ubsan.cpp
<heat> I don't actually know what's the best course of action here
<geist> hmm i dont see it. what config shows it?
<geist> currently building riscv
<heat> i think riscv also shows it
<geist> ah 32bit seems to be the key
<heat> hah!
<heat> I see!
<heat> it probably defines size_t as unsigned int
<heat> so it wants an int ssize_t
<heat> https://github.com/littlekernel/lk/actions/runs/4213585738/jobs/7313381130#step:7:197
<heat> it's pretty detailed there
<geist> fwiw for the purposes of the warning it seems that literally setting it to `signed size_t` makes it go away
<geist> though dunno if that's correct
<geist> yah i have it checked out in front of me now
<heat> did you try it?
<geist> well, at least on the sprintf
<heat> i have 0 idea how defined signed unsigned int is :)
<geist> it's a long, but yeah
<geist> well, will have to debug a bit later. need to get going soon
<geist> file a bug about it so one of us doesn't forget
<geist> i might have to revisit the exact type of ssize_t, and/or not use it here
<geist> deep in the types.h i have it set to a signed long, to match the unsigned long size_t is
<geist> and i remember having to do that vs defining it as a `signed size_t` because i thnk the latter isn't valid
<geist> ie, the signed flag doesn't override the unsigned flag
<geist> but also some of those old assumptions may no longer be correct. i'm always finding out that those early decisions are wrong
<heat> yeah and in this case it's not an unsigned long but an unsigned
<heat> (uint)