C include format error

[aotto1968]

Describe the bug a @include of a C file fails with an format error. the problem is a "#" in a string which is wrong parsed

Screenshots

To Reproduce use attachment: doxygen_bug__include_c.tar.gz

Expected behavior no format error

Version

doxygen -V 1.13.0 (b75f8d594a78a986352bda81ce3b94d15d4f4aae) with sqlite3 3.42.0.

[albert-github]

I think the problem is in the line:

  MkBufferCreateLOCAL_T(MkBuffer1024C,buf,0)

which should read:

  MkBufferCreateLOCAL_T(MkBuffer1024C,buf,0);

so a missing ; and the resulting code is not valid C code.

I think the problem is usage.

[aotto1968]

ok, this is your point but it is a macro and the ";" is part of the macro

__parser__(constructor,macro,doc-sort=tmpl2)
void MkBufferCreateLOCAL_T(MK_MACRO_TYP cls, MK_MACRO_TYP name, MK_NUM const size);
/// \brief create an new \RMkBufferC object as L)ocal S)torage…
///
/// The \arg{cls} argument is:  \RMkBuffer64S 64 bytes, \RMkBuffer256S = 256 bytes, 
///                             \RMkBuffer1024S = 1024 bytes,
///
/// \par hint
/// access \e string with `bufR.super.buf.storage.first.C`
///
/// \param_MkBufferS_cls
/// \param name   the \e name of the new \RMkBufferC
/// \param size   the initial \e size of the new \RMkBufferC
///
/// \snippet{lineno} kernel_mk.h MkBufferCreateLOCAL_T
// [MkBufferCreateLOCAL_T]
#define MkBufferCreateLOCAL_T(cls,name,size)        \
  cls##R name##R = {0};                             \
  struct MkBufferS * const name = MkBUF(&name##R);  \
  MkBufferInit(name,cls##_TT,size);                 \
// [MkBufferCreateLOCAL_T]

[albert-github]

The problem here is that doxygen has no idea about the #define (even when the file kernel_mk.h is included), doxygen is not a compiler and does not preprocess the code for for showing with SOURCE_BROWSER=YES or with the \include command.

The problem will also occur when e.g.:

MkRtSetup_NULL;

is missing the ;.

The missing of a ; at the end of a "call" to a defined entry is, to the best of my knowledge, not really advised (and when a define is used in a conditional statement it might give some surprising results) but not against the standard though.

The statements:

__parser__(constructor,macro,doc-sort=tmpl2)
void MkBufferCreateLOCAL_T(MK_MACRO_TYP cls, MK_MACRO_TYP name, MK_NUM const size);

are also confusing as here it looks like MkBufferCreateLOCAL_T is a real function (I assume that __parser__... is some directive for a specific compile / preprocessor.

[aotto1968]

that is the reason why I near always use the /usr/bin/source-highlight tool and use htmlinclude to do syntax-highlighting in doxygen. The core problem is that doxygen only support a limit number of languages and even if supported there are a couple of problems.

→ /usr/bin/source-highlight has no problem with the files from above: → http://thedev.nhi1.de/theLink/main/perfclient.htm

[albert-github]

• Does source-highlight exists for all major platforms?
• Does source-highlight have the ability to link back to the documentation and vice versa?

[aotto1968]

look at → https://www.gnu.org/software/src-highlite/

I use: <div class="htmlcode"> \htmlinclude perfclient.c.html </div> as include with my css

css:

div.htmlcode {
  /* from div.fragment */
  padding: 0 0 1px 0; /*Fixed: last line underline overlap border*/
  margin: 4px 8px 4px 2px;
  background-color: #FBFCFD;
  border: 1px solid #C4CFE5;

  font-family: monospace, fixed;
  font-size: 13px;
  min-height: 13px;
  line-height: 1.0;
}

the link-back feature is indirect available because they do XHTML output of the parsed source - this have than be processed. BUT it should not be as difficult to extend this SW (stylesheet?) to add an callback for additional style information.

[albert-github]

I've just pushed a proposed patch, pull request #11087

[albert-github]

Code has been integrated in master on GitHub (please don't close the issue as this will be done at the moment of an official release).

[doxygen]

This issue was previously marked 'fixed but not released', which means it should be fixed in doxygen version 1.13.0. Please verify if this is indeed the case. Reopen the issue if you think it is not fixed and please include any additional information that you think can be relevant (preferably in the form of a self-contained example).