New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

conditional code in #ifndef not properly handled (Origin: bugzilla #582469) #3388

doxygen opened this Issue Jul 2, 2018 · 0 comments


None yet
1 participant

doxygen commented Jul 2, 2018

status RESOLVED severity normal in component general for ---
Reported in version 1.5.9 on platform Other
Assigned to: Dimitri van Heesch

Original attachment names and IDs:

On 2009-05-13 14:18:52 +0000, Clemens wrote:


If conditional code is encapsulated in #ifndef / #endif and the first comment block is a #define documentation for the same macro that is used for the conditional block, then documentation for that first #define is missing or assigned to some other #define documentation.

Test cases:

The macors ABC and XYZ are not predefined.
In case-1 the documentation for ABC is missing. While documentation for XZY steels its text from ABC-ABC. Case-2 is equal to case-1, only the order of ABC and XYZ is changed. The output is ok for case-2.

Case 1:

#ifndef ABC

/// ABC-ABC.
#define ABC

/// XYZ-XYZ.
#define XYZ


HTML Output:
Define Documentation

<<< where is docu for ABC ?? <<<

#define XYZ
ABC-ABC. <<< stolen from ABC <<<
Definition at line 12 of file def.c.

Case 2:

#ifndef ABC

/// XYZ-XYZ.
#define XYZ

/// ABC-ABC.
#define ABC


Config File:


On 2009-05-13 14:28:27 +0000, Clemens wrote:

Created attachment 134569
test case

This ZIP contains one C source file which causes the problem. Also there is the config file and the corresponding HTML output.

On 2009-05-13 14:32:09 +0000, Clemens wrote:

This issue came up in the Doxygen mailing list under the topic "Wrestling with #ifndef - #define in C" on 2009/05/08.

On 2009-05-14 20:19:48 +0000, Dimitri van Heesch wrote:

Confirmed. The problem is related to doxygen's special treatment of include guards of the form

#ifndef BLAH
#define BLAH


In this case the BLAH is absorbed to avoid a #define in every include file with a guard (i.e. every well defined include file), but in your case the comment stays and is later on joined with the next comment block.

To fix the problem, I'll disable the guard detector when a doxygen comment is found.

On 2009-06-04 12:29:08 +0000, Clemens wrote:

Until this bug will hopefully be fixed in the next version of doxygen, the following workaround can be used:

#ifndef ABC

/// see

/// ABC-ABC.
#define ABC


The idea of the workaround is to put some other #define before the ABC #define.

In other words:
If #ifndef ABC/#endif blocks are used then a doxygen commented #define ABC must not be the first item inside this block. Put some #define before it.

On 2009-08-20 10:13:01 +0000, Dimitri van Heesch wrote:

This bug was previously marked ASSIGNED, which means it should be fixed in
doxygen version 1.6.0. Please verify if this is indeed the case and reopen the
bug if you think it is not fixed (include any additional information that you
think can be relevant).

On 2009-08-20 14:21:39 +0000, Clemens wrote:

Perfect. The test case work correctly now with Doxygen 1.6.0.
Thanks Dimitri.

On 2010-04-16 15:05:00 +0000, RichardM wrote:

Is there any chance the bug can be fixed so that modifying the code being parsed is not required?

On 2010-06-10 14:50:50 +0000, Clemens wrote:

Richard, this bug is fixed since version 1.6.0. See Dimitris comment from 2009-08-20. I can confirm, that 1.6.0 now works as expected for the provided test case. I have once again tested with the latest version 1.6.3: it works as expected.


On 2010-06-10 18:16:02 +0000, RichardM wrote:

It may work for your test case, but it doesn't with the code I'm stuck with. We have version 1.6.3 and are attempting to use it on a set of software with around 2,000 include files, none of which can be modified (this is for a government contract with fairly tight rules on what can be modified).

On 2010-06-11 08:16:10 +0000, Clemens wrote:

(In reply to comment # 9)

It may work for your test case, but it doesn't with the code I'm stuck with.

Richard. These are certainly bad news. I also understand that you cannot use the proposed workaround.

I think you should create an own test case based on your code, attach it to this bug ticket and reopen the bug. The test case should be the smallest amount of code which reproduces the error.


@doxygen doxygen closed this Jul 2, 2018

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment