Re: Address MISRA C:2012 Rule 8.4

[Jan Beulich <jbeulich@xxxxxxxx>]

On 04.08.2023 11:47, Nicola Vetrini wrote:
> Upon further examination, I identified the following patterns:
> 
> 1. Functions defined in .c called only from asm code (e.g., the already 
> mentioned __start_xen)
> 2. Functions/variables declared in a .h, defined in a .c that does not 
> include the .h with the declaration
> (e.g., 'fill_console_start_info' is defined in 'xen/drivers/vga.c', 
> declared in 'xen/include/xen/console.h' which is not visible when 
> compiling the .c).
> 3. Variables that are either extern or not, such as 'acpi_gbl_FADT' in 
> 'xen/include/acpi/acglobal.h', depending on
>     DEFINE_ACPI_GLOBALS
> 
> Below are the proposed resolution strategies:
> 
> 1. I would advise to add the declaration in the relative .h, to support 
> automatic consistency checks with the
>     implementation and a quick reference when touching the asm.

That'll need discussing first.

> 2. To comply with the rule, the header with the declaration should be 
> included. Also note that there are some
>     corner cases, such as 'get_sec', which is used in 'cper.h' without 
> including 'time.h' (which should gain a
>     declaration for it).

This one of course wants fixing wherever found.

> 3. One possible resolution pattern is including 'acglobal.h' twice 
> (either directly or indirectly trough acpi.h, if
>     the latter does not cause other issues) like so:
> 
>     (assuming DEFINE_ACPI_GLOBALS is undefined here)
>     #include "acglobal.h"
>     #define DEFINE_ACPI_GLOBALS
>     #include  "acglobal.h"
> 
>    this way, the rule is followed properly, though it's not the prettiest 
> pattern and also clashes with the objectives
>    of D4.10 ("Precautions shall be taken in order to prevent the contents 
> of a header file being included
>    more than once"), but then a motivated exception is allowed there.

Not really sure about this one.

Jan