[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [XEN PATCH][for-4.19 v2 2/2] docs/misra: add deviations.rst to document additional deviations.




+
+   * - R2.1
+ - The compiler implementation guarantees that the unreachable code
is
+ removed. Constant expressions and unreachable branches of if and
switch
+       statements are expected.
+     - Tagged as `safe` for ECLAIR.
+
+   * - R2.1
+     - Some functions are intended not to be referenced.
+     - Tagged as `deliberate` for ECLAIR.

What does it mean "some functions" in this case? Should we list which
functions?


Well, there are a lot, typically resulting from build configurations that do
not
use them, or because they are used only in asm code. I can mention these
reasons in the
document, to make it easier to understand.

Yes, I think we need to clarify further this point, because saying "Some
functions" doesn't help the reader understand:
- whether all functions can be not referenced
- which subset of functions can be not referenced

How to distinguish between? How do we know whether a certain patch is
violating the rule or not?

If there is a clear list of functions that can be not referenced, then
we should list them here. If there is a methodology we can use to
distinguish between them (e.g. functions called from asm only) then we
can write the methodology here. Either way it is fine as long as the
criteria to know if it is OK if a function is not referenced is clear.

Aren't they more or less the one we tagged with SAF-1-safe because
there were no prototype? If so, we could use the same tags.

We could introduce an extra tags for the others. An alternative would
be to add an attribute (e.g. asmcall) to mark each function used by
assembly.

Cheers,

Both suggestion do have some value. As it is, it's not distinguishable what causes a
function to be unreferenced in a certain analysis config. However:

- functions only used by asm code can be specified in the ECLAIR config so that they will have an extra fake reference as far as the checker is concerned. I can do that on a separate patch and list them in deviations.rst. An attribute seems a good way to signal the
  intention.
- Functions that have no reference only in the current analysis should have their declaration #ifdef-ed out in the configurations where they are not used, in an ideal world.
- Truly unreferenced functions should be removed, or justified

--
Nicola Vetrini, BSc
Software Engineer, BUGSENG srl (https://bugseng.com)



 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.