lfs_stat: Fields are left uninitialized in some cases

[rojer]

lfs_stat() leaves info fields uninitialized in some cases.
one particular case i hit: stat("/") only sets the type and name and leaves everything else untouched (= possibly uninitialized).

[geky]

Ah, I believe this is limited to info.size, which is not well-defined for directories (and root).

This has actually already been changed in littlefs3 (#1111, unstable), to set info.size to zero:

littlefs/lfs3.c

Lines 11899 to 11900 in 2d68db9

	// default size to zero
	info->size = 0;

In theory we can do the same in littlefs2, but I think it may need to wait for a minor release. There's a small chance users do something like:

struct lfs_info info;
info.size = 42;
lfs_stat(&lfs, "blablabla", &info) => 0;
// expect info.size == 42 for directories

[rojer]

littlefs-fuse leaves struct lfs_info uninited (in both cases) and this results in weird numbers in ls -l output - that's how i found it.

[rojer]

i think the general understanding is that if you're passing a struct to be filled, the callee can fill it. i'd just memset() it to 0 right there, in lfs_stat() before doing anything. uninitialized values and associated undefined behavior leads to by far the nastiest heisenbugs in existence, that's why i always init my vars, so all my other uses had = {0} next to then and were thus unaffected.

[geky]

We put littlefs through Valgrind, which usually catches uninitialized reads. Though in this case none of the tests check info.size when type is dir. It's arguably undefined behavior, but setting it to zero is safer.

i think the general understanding is that if you're passing a struct to be filled, the callee can fill it.

Though this toes the line between a bug fix and behavior change. The problem is littlefs is used in a large number of projects, which makes the risk of breaking downstream code high even if the change is innocent, https://xkcd.com/1172. Keep in mind this function has had this behavior for ~8 years.

littlefs-fuse leaves struct lfs_info uninited (in both cases) and this results in weird numbers in ls

At least this is a low-risk fix in lfs-fuse.