Re: [RFC] k_poll_signal name and MISRA

Paul Sokolovsky


On Mon, 29 Oct 2018 08:48:46 +0100
"Erwan Gouriou" <erwan.gouriou@...> wrote:

Making different names is good, but then I think one should be able to
identify quickly which is struct and which isn't,
What about k_struct_poll_signal or k_poll_signal_struct ?
Well, that should be simple: a noun is a struct, so k_poll_signal
remains a structure. A subroutine which performs action should contain
a verb. To avoid tautology, it may be k_poll_signal_set(). Or perhaps,
signals are raised? Then k_poll_signal_raise().

That's a basic idea which many projects follow, and which is mostly,
but not consistently, seems to be followed by Zephyr. As many other
things in Zephyr, such conventions would rather be formalized.

Flavio, one good way to approach questions like this is to do some
research/analysis and offer 3-4 alternative variants for people to
choose from (or base further alternatives on). Fairly speaking, I didn't
reply earlier in this thread, because I wanted to do such an analysis
myself, but as usual, it's backlogged by other tasks.

A variant presented above is just a "low-hanging" one. We could go
further, e.g.

2. Challenge the name "signal", it may be confusing.
3. Challenge the "_poll" infix part of the name, that's again
confusing due to noun/verb ambiguity.


On Thu, 25 Oct 2018 at 22:07, Flavio Ceolin <flavio.ceolin@...>

Hi guys,

MISRA-C rule 5.7 says that a tag name shall be a unique identifier,
also reuse tag names is an undefined behavior recognized in C99

It happens that we have in Zephyr both a struct and a function
called k_poll_signal (there may be others cases in the project),
the question is, what it is preferable, change the function to
something like, k_pll_signal_signal() or change the struct nam ? In
the latter, what is the suggestion ? Remembering that I'll follow
this pattern if necessary.

Flavio Ceolin

Best Regards,
Paul | Open source software for ARM SoCs
Follow Linaro:!/linaroorg -

Join to automatically receive all group messages.