Error while documenting a C function with array as argument

[jbp0ns]

Setup

• doxygen v1.8.13
• WSL2 Ubuntu 18.04 on Windows 10 22H2

Context
I want to document the following function defined in my_lib.h:

/**
 * @brief Compute CRC
 *
 * @param [in] buf : my buf
 * @param [in] size : size of my buf
 * @param [out] crc_buf : buffer containing crc results
 */
void my_lib_compute_crc(uint8_t *buf, unsigned int size,
                           uint8_t crc_buf[CRC_SIZE]);

Its definition is located in my_lib.c file:

void my_lib_compute_crc(uint8_t *buf, unsigned int size,
                           uint8_t crc_buf[CRC_SIZE])
{
        uint16_t crc;

        crc = 12;

        memcpy(crc_buf, &crc, sizeof(crc));
}

Problem
When I execute doxygen I've the following error:

Generating docs for file my_lib.c...
src/my_lib.c:20: error: Member my_lib_compute_crc(uint8_t *buf, unsigned int size, uint8_t crc_buf[CRC_SIZE]) (function) of file my_lib.c is not documented. (warning treated as error, aborting now)

I know that the Doxygen version I used is pretty old but I didn't succeeded to find a similar issue already managed in Doxygen release changelogs nor Github issues.

Note
You can find my complet projet into the attached zip archive. There is my Doxyfile in it.
doxygen_array_fn_param_issue.zip

[albert-github]

It looks like that the part:

                           uint8_t crc_buf[CRC_SIZE])

and more specific the part CRC_SIZE is the problematic part.

I tested it with the current release 1.10.0 as well and here the problem is still present, nevertheless it would anyway be advisable to update from 1.8.13 to 1.10.0

[jbp0ns]

Thank you for your quick answer.

Can I use a workaround or a specific configuration on Doxyfile to tell Doxygen to ignore this object and generate the documentation after all?

[albert-github]

Maybe you could use the setting

PREDEFINED = CRC_SIZE=

though this might have some size effects on other places where CRC_SIZE is used / defined.

[jbp0ns]

This solved my problem. I'm able to generate full documentation now.

As this function prototype syntax is valid, does the issue will be treated?

[albert-github]

As this function prototype syntax is valid, does the issue will be treated?

Probably yes, though it all depends on the time available ...

[albert-github]

When running doxygen -d preprocessor it gives for my_lib.c:

#include my_lib.h: not found! skipping...

Doxygen is, just like compilers, a bit picky about include files so we need INCLUDE_PATH = includes, just having them as INPUT files is not sufficient.

As far as I can tell this solves the issue, and is not a bug but usage.

[doxygen]

@albert-github Although your suggested solution works, I think we can still do a bit better, so I've added a fallback that avoids the need to specify the INCLUDE_PATH in case the header can be found in the input and has a unique name.

[albert-github]

As such I think it is a good idea, but we have to keep our eyes open for "strange" effects (e.g. with relative paths etc.).