Doxygen throws undesirable [read][write] attribute into output documentation (Origin: bugzilla #598497)

[doxygen]

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

On 2009-10-14 21:59:24 +0000, Lori Boyters wrote:

Sent problem to Dimitri, who determined that this is a bug (see email below). Although I was using Doxygen 1.6.1, it also occurs in Doxygen 1.5.9, which is the desired version we wish this fix to be in. Also, is there a way to install this as a patch to Doxygen 1.5.9 as we don't want to upgrade to the later versions of Doxygen.

Thanks,

Hi Lori,

On Mon, Sep 28, 2009 at 03:50:00PM -0700, Boyters, Lori wrote:

Hey again Dimitri, I put together a small sample of what we are receiving in our output documentation (HTML) that is undesirable, to see if you have any suggestions on how to turn this off.

I'm using Doxygen 1.6.1 on Windows XP.
The developer was able to run this using Doxygen 1.5.1 and does not receive the [read] [write] attributes, but I don't want to go back to that version as we need many of the new features and fixes in the later Doxygen versions.
BTW I did find the [read] attribute in the LaTeX file as
\mbox{[}read\mbox{]} - which is why I couldn't find it before when I searched for "[read]"-thanks for the hint on that.
As a Workaround, I'll need to strip out the string in the .tex files prior to running the PDF, but this goes against our goal to have a single source automated documentation process.

Look forward to your response.

You found a bug!

Can you file it in the bug tracker? That way you will be notified when it is fixed and I don't forget about it.

Regards,
Dimitri

On 2009-10-15 19:20:47 +0000, Dimitri van Heesch wrote:

Confirmed. Should be fixed in the latest SVN snapshot already.

On 2009-12-30 13:38:31 +0000, Dimitri van Heesch wrote:

This bug was previously marked ASSIGNED, which means it should be fixed in
doxygen version 1.6.2. 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 2010-05-24 22:46:00 +0000, Lori Boyters wrote:

Have the same issue with [static]. Refer to the attached header file and PDF, paragraph 8.2.2.1, page 21.

On 2010-05-24 22:54:45 +0000, Lori Boyters wrote:

Same issue with [private] and [virtual]

On 2010-06-05 12:58:45 +0000, Dimitri van Heesch wrote:

Hi Lori, the function in 8.2.2.1 is static, so the [static] qualifier is correct here. Probably the same holds for the others?

I get the idea that you do not want to see any qualifier at all.
There is no option to disable them however.

For C++ these are quite handy as the declaration alone is not enough to see what attributes (like [virtual], [private], [protected], [static]) a member has.
For C code it is less relevant, since there a static function is already marked as such. I just added the qualifiers there as well for consistency reasons.

On 2010-10-28 13:21:35 +0000, Tobias Mueller wrote:

Assuming this to be OBSOLETE based on comment # 5. Please reopen if this is not the case. Thanks in advance.

On 2010-10-28 13:28:04 +0000, Dimitri van Heesch wrote:

Hi Tobias,

I'm not sure what you mean with your remark.

If you think there is still a problem please attach a self-contained example and a clear description and I'll reopen the bug report (alternatively, you could also file a new one).