drivers/flash: fix warnings about missing casts

[szundi]

fix warnings about missing casts in /include/drivers/flash.h on the dev->driver_api
fixes #21290
Signed-off-by: András Szabó [email protected]

[zephyrbot]

Some checks failed. Please fix and resubmit.

Gitlint issues

3: B2 Line has trailing whitespace: "fix warnings about missing casts "

Tip: The bot edits this comment instead of posting a new one, so you can check the comment's history to see earlier messages.

[szundi]

is it possible that ${ZEPHYR_BASE}/scripts/checkpatch.pl check for 80 long lines, but the bot here checks if it is <72?

[stephanosio]

is it possible that ${ZEPHYR_BASE}/scripts/checkpatch.pl check for 80 long lines, but the bot here checks if it is <72?

@szundi It is referring to the commit message.

[stephanosio]

I think we should really establish guidelines on handling these C++ issues.

These implicit void pointer conversions are perfectly valid and even encouraged in C (e.g. when using malloc), while C++ is very pedantic about it; in fact, the only reason we are not getting an error for this is that we specify -fpermissive.

IMHO, since these headers primarily target C and such explicit casts involving void * are both redundant and (arguably) ugly, I think we should leave them as is and ignore the warnings.

#11371 (review)

[nvlsianpu]

Normally rather need to fix current PR than close it and open its replacement
https://docs.zephyrproject.org/latest/contribute/index.html#contribution-workflow

[nvlsianpu]

Normally rather need to fix current PR than close it and open its replacement
https://docs.zephyrproject.org/latest/contribute/index.html#contribution-workflow

Pleas fix commit message this way.

[szundi]

@stephanosio I feel you too, but default zephyr setting build should not spam warnings in my opinion. They need to make policy change, otherwise someone has to make these go away. Strategically I don't really see where this goes, so if it is against long term strategy, I am happy to see this fix trashed for good - otherwise I feel this beautiful 😉

[pabigot]

IMHO, since these headers primarily target C and such explicit casts involving void * are both redundant and (arguably) ugly, I think we should leave them as is and ignore the warnings.

I sympathize, but these headers provide the implementation of the flash API, and if they are incorrect the flash API can't be used.

I was already reconsidering my approval, and so now I'm withdrawing it in favor of opening #21365 as the general case. I believe much of the conversion can be automated with Coccinelle.

Reconsidered

[stephanosio]

I feel you too, but default zephyr setting build should not spam warnings in my opinion.

Ideally, these warnings should be allowed to be turned off as they were before; but unfortunately, the gcc guys are as much of void * haters as the ISO C++ guys; so, I guess that is not happening anytime soon.

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81787

I wonder if writing a wrapper for g++ that filters out the -fpermissive warnings involving implicit void * type conversions could be an option.

Alternatively, we could patch the g++ in the Zephyr SDK to add an option like -Wno-implicit-void-pointer-type-conversion.

[szundi]

I feel you too, but default zephyr setting build should not spam warnings in my opinion.

Ideally, these warnings should be allowed to be turned off as they were before; but unfortunately, the gcc guys are as much of void * haters as the ISO C++ guys; so, I guess that is not happening anytime soon.

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81787

I wonder if writing a wrapper for g++ that filters out the -fpermissive warnings involving implicit void * type conversions could be an option.

Alternatively, we could patch the g++ in the Zephyr SDK to add an option like -Wno-implicit-void-pointer-type-conversion.

This gcc patch idea is nice. Maybe this casting is just waste of work, does not mean any benefit when later something changes. However on Mac, there is no zephyr SDK.

[pabigot]

@szundi please see #21391. Thanks for raising this concern.

[stephanosio]

This gcc patch idea is nice. Maybe this casting is just waste of work, does not mean any benefit when later something changes. However on Mac, there is no zephyr SDK.

#21365 (comment)

@szundi It seems that Clang is even more pedantic about it and, at that point, I suppose we have no other option but to appease the C++ specs.

@pabigot is working on establishing the de facto guidelines for this (#21365, #21391, #21392).

[pabigot]

Superseded by #21391