Fix lfs_gstate_hasmove always return 0 if bool is defined as uint8_t.

[XinStellaris]

static inline bool lfs_gstate_hasmove(const lfs_gstate_t *a) {
return lfs_tag_type1(a->tag);
}
if bool is defined as uint8_t, this function always return 0. This is caused by truncate return value of uint16_t to uint8.

I have also notice other functions may have the same bug, they are:
lfs_gstate_getorphans
lfs_gstate_hasorphans
I am not sure about them though.

Signed-off-by: 田昕 tianxin7@xiaomi.com

[XinStellaris]

Need your review @geky
Especially I need your opinion on following functions:
lfs_gstate_getorphans
lfs_gstate_hasorphans

[geky]

Hi @XinStellaris, sorry about the late response. Thanks for creating a PR.

This is a bit of a puzzle, the fix seems obvious but I'm hesitant to accept it. I'm assuming this is caused by a non-standard compiler? In c99 any non-zero value should be converted to true here. Out of curiosity what compiler/target are you using?

It seems like an easy fix, but using a non-compliant compiler is fragile. There may be other bugs hidden by compiler differences like this one. And future littlefs changes could introduce these hidden bugs in the future without some sort of check in CI.

Unfortunately adopting a pre-c99 standard loses too many quality-of-life features, some which also help prevent bugs. So littlefs sticks to c99 at the risk of less compiler support. It would be valuable to also have a c89 compliant codebase, perhaps using some sort of C->C compiler, but that is out of scope for now.

[XinStellaris]

I am using RISC-V, target board is esp32c3.
Yes we didn't use C99 bool in our case, but it can be enabled.
We will enable C99 bool in the future.

As for now, I think it is acceptable to leave a closed pr here without merging. Hope this PR will warn others using C89 that their code will not work properly(In our case, the whole littlefs will fall into unrecoverable state)

[geky]

Hi @XinStellaris, just an FYI, this cropped up again in #772, so I've opened a PR to add an explicit assert to hopefully prevent others from running into this in the future: #801