Fix compilation error bad-function-cast.

[opilat]

Fix compilation error bad-function-cast.

error: cast from function call of type '_Bool' to non-matching type 'unsigned int' [-Werror=bad-function-cast]

[geky]

Hi @opilat, thanks for creating a PR.

I'm not sure I really see the value of this warning, at least for littlefs, and it doesn't seem to be present in -Wall or -Wextra. Have you considered just disabling this warning for littlefs in your build system?

[opilat]

Hi Christopher, we have it disabled in our build system for littlefs code. We aim to have no such exceptions. Disabling specific warnings for parts of build make configuration slightly confusing. The proposed change is more defensive code style and still worth of merge. What if /lfs_gstate_hasorphans/ changes its return value? Regards Ondrej Dne 21.03.2022 v 3:17 Christopher Haster napsal(a):

Hi @opilat <https://github.com/opilat>, thanks for creating a PR. I'm not sure I really see the value of this warning, at least for littlefs, and it doesn't seem to be present in |-Wall| or |-Wextra|. Have you considered just disabling this warning for littlefs in your build system? — Reply to this email directly, view it on GitHub <#609 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AQCVF6G4F7QEM254MM5EETTVA7L4DANCNFSM5HSRMT4A>. Triage notifications on the go with GitHub Mobile for iOS <https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android <https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>. You are receiving this because you were mentioned.Message ID: ***@***.***>

--

[geky]

The proposed change is more defensive code style and still worth of
merge. What if /lfs_gstate_hasorphans/ changes its return value?

I'm less concerned with the current code and more concerned with future changes. littlefs is still being developed and some of the more aggressive warnings we accepted have caused more problems than benefits (mostly -Wshadow).

I'm also struggling to understand the defensive value of this warning, from reading up on it seem to be for catching implicitly defined functions, but this is something modern version of GCC have an explicit warning for.

---

Disabling specific warnings for parts of build make configuration slightly confusing.

On the other hand it makes it easier to upgrade your compiler, since a compiler upgrade no longer risks needing to fix warnings in depended projects. Just from my small experience external warnings quickly get too time-consuming to fix when you have many dependencies.

[vonj]

My strategy is to only explicitly ENABLE warnings. That is more robust in the face of compiler upgrades. (I.e. white list, not black list.)

…

23 mars 2022 kl. 04:17 skrev Christopher Haster ***@***.***>:  The proposed change is more defensive code style and still worth of merge. What if /lfs_gstate_hasorphans/ changes its return value? I'm less concerned with the current code and more concerned with future changes. littlefs is still being developed and some of the more aggressive warnings we accepted have caused more problems than benefits (mostly -Wshadow). I'm also struggling to understand the defensive value of this warning, from reading up on it seem to be for catching implicitly defined functions, but this is something modern version of GCC have an explicit warning for. Disabling specific warnings for parts of build make configuration slightly confusing. On the other hand it makes it easier to upgrade your compiler, since a compiler upgrade no longer risks needing to fix warnings in depended projects. Just from my small experience external warnings quickly get too time-consuming to fix when you have many dependencies. — Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you are subscribed to this thread.

[geky]

@vonj that sounds reasonable. Assuming you are not using -Wall and instead have the warning list explicit (which sounds doable).

I'd still advocate for separate warning flags for the code you are working on and for dependencies. You want to know as much information about the code you are working on to know possible sources of errors. But for dependencies this approaches noise. And any code change carries its own risk of unintentionally introducing a bug.