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 134216 - Improper handling of '\"' in source
Improper handling of '\"' in source
Status: RESOLVED FIXED
Product: doxygen
Classification: Other
Component: build
1.3.x
Other OSF/1
: Normal normal
: ---
Assigned To: Dimitri van Heesch
Dimitri van Heesch
Depends on:
Blocks:
 
 
Reported: 2004-02-12 14:28 UTC by josh.watson
Modified: 2013-03-31 03:34 UTC
See Also:
GNOME target: ---
GNOME version: ---

Attachments
Demonstration of bug (should compile on most platforms) (1.27 KB, text/plain)
2004-02-12 14:43 UTC, josh.watson 		Details

Description josh.watson 2004-02-12 14:28:30 UTC 
Similar to bug 120708 , doxygen release 1.3.5 had trouble with my header
file which contains " marks as char values. The bug also manifests itself
with the string '"' (this won't compile though).


The line that affects doxygen is 

const unsigned char DQUOT = '\"';

If this line is included, doxygen reports that all commands in single line
comments after this point in the file are not valid in single line
comments, even though they are.

I can't release the code this occurs in, but will prepare a file that
triggers this bug.

Keep up the good work!
Comment 1 josh.watson 2004-02-12 14:30:53 UTC 
A workaround for this bug is detailed below:

const unsigned char DQUOT = '\"';
///"

Doxygen continues to parse the file correctly in this case.
Comment 2 josh.watson 2004-02-12 14:43:21 UTC 
Created attachment 24349 [details]
Demonstration of bug (should compile on most platforms)
Comment 3 Gerik Rhoden 2004-02-24 12:45:53 UTC 
It also occurs in function bodies:
{
  char* t = '\"';          

  if (*s == '\"');    
    *t++ = '"';         // fix "
}
A single " in a comment before the next comment block will then fix 
the problem.

Note that the help text generated after this is wrong, it is not 
just a spurious warning. A comment block like:
/// Function 1.
/// \note Note for function 1.
/// \return self

generates the following:
Function 1. Note for function 1. self.
Comment 4 Thomas Dickey 2005-12-12 20:44:20 UTC 
This is essentially the problem still present in #320975
(the parser cannot handle ordinary C syntax).  Here's
a more typical example, which I noticed because doxygen
generated an error message:

#if USE_OFFSETS
    Fprintf(fp,
            "#ifndef\tMember_Offset\n\ 
#define\tMember_Offset(T,M) ((int)(((long)&(((T*)0)->M))/\\\n\ 
\t\t\t\t ((long)&(((T*)0)->Q1) - (long)&(((T*)0)->s_MAX))))\n\ 
#endif\n");
#else
    Fprintf(fp,
            "#ifndef\tMember_Offset\n\ 
#define\tMember_Offset(T,M) ((vile_ ## M)-1)\n\ 
#endif\n");
#endif
Comment 5 Kevin McBride 2005-12-21 23:40:55 UTC 
oops, I modified the assignee of the wrong bug.
Comment 6 Kevin McBride 2013-03-31 03:34:23 UTC 
I have triaged this bug, and determined that the bug appears to be fixed in 1.8.3.1.  If you still have problems with the latest version of doxygen, please reopen this bug and attach a sample in a tar or zip.