After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 582469 - conditional code in #ifndef not properly handled
conditional code in #ifndef not properly handled
Status: RESOLVED FIXED
Product: doxygen
Classification: Other
Component: general
1.5.9
Other Windows
: Normal normal
: ---
Assigned To: Dimitri van Heesch
Dimitri van Heesch
Depends on:
Blocks:
 
 
Reported: 2009-05-13 14:18 UTC by Clemens
Modified: 2010-06-11 08:16 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
test case (3.23 KB, application/octet-stream)
2009-05-13 14:28 UTC, Clemens
Details

Description Clemens 2009-05-13 14:18:52 UTC
Problem: 
--------

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

#endif

HTML Output:
  Define Documentation

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

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


__Case 2:__

#ifndef ABC

/// XYZ-XYZ.
#define XYZ

/// ABC-ABC.
#define ABC

#endif

Config File:
------------

ENABLE_PREPROCESSING   = YES
MACRO_EXPANSION        = NO
EXPAND_ONLY_PREDEF     = NO
SEARCH_INCLUDES        = YES
INCLUDE_PATH           =
INCLUDE_FILE_PATTERNS  =
PREDEFINED             =
EXPAND_AS_DEFINED      =
SKIP_FUNCTION_MACROS   = YES
Comment 1 Clemens 2009-05-13 14:28:27 UTC
Created attachment 134569 [details]
test case

This ZIP contains one C source file which causes the problem. Also there is the config file and the corresponding HTML output.
Comment 2 Clemens 2009-05-13 14:32:09 UTC
This issue came up in the Doxygen mailing list under the topic "Wrestling with #ifndef - #define in C" on 2009/05/08.
Comment 3 Dimitri van Heesch 2009-05-14 20:19:48 UTC
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. 
 
Comment 4 Clemens 2009-06-04 12:29:08 UTC
Until this bug will hopefully be fixed in the next version of doxygen, the following workaround can be used:

#ifndef ABC

/// see http://bugzilla.gnome.org/show_bug.cgi?id=582469
#define SOME_OTHER_DEFINE

/// ABC-ABC.
#define ABC

#endif

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.
Comment 5 Dimitri van Heesch 2009-08-20 10:13:01 UTC
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).
Comment 6 Clemens 2009-08-20 14:21:39 UTC
Perfect. The test case work correctly now with Doxygen 1.6.0. 
Thanks Dimitri.
Comment 7 RichardM 2010-04-16 15:05:00 UTC
Is there any chance the bug can be fixed so that modifying the code being parsed is not required?
Comment 8 Clemens 2010-06-10 14:50:50 UTC
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.

Clemens
Comment 9 RichardM 2010-06-10 18:16:02 UTC
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).
Comment 10 Clemens 2010-06-11 08:16:10 UTC
(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.

Clemens