| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |\ |
|
| | |\
| | |
| | | |
Email address seen as code starter
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Some email addresses give problems in the comment converter as they contain e.g. `@code`, so we try to detect Email addresses (analogous to doctokenizer.l) to prevent these false positives.
The given warning would ne like:
```
aa.h:13: warning: Reached end of file while still inside a (nested) comment. Nesting level 1 (probable line reference: 1)
```
|
| | |\ \
| | | |
| | | | |
Incorrect NCName in docbook citations
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
In a bibtex reference it is possible to have a colon as the id, but in docbook this will result in:
```
docbook/citelist.xml:5: validity error : xml:id : attribute value _citelist_1CITEREF_pre:post is not an NCName
<varlistentry><term><anchor xml:id="_citelist_1CITEREF_pre:post"/>[1]</term>
```
So the id has to be translated. A colon in an id can only happen in case the names is provided from the outside.
|
| | |\ \ \
| | | | |
| | | | | |
Fix incorrect reference resolving of enum class values
|
| | | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
When they share enum value names inside the same namespace.
This is a proposed fix for issue #7427: "Incorrect resolving of
references to enum class values with shared names inside the same
namespace"
|
| |/ / / /
| | | |
| | | |
| | | | |
the content
|
| |\ \ \ \ |
|
| | |\ \ \ \ |
|
| | | | | | |
| | | | | |
| | | | | |
| | | | | | |
Fixing a number of uninitialized variables based on the coverity output of November 30, 2019
|
| | | | | | | |
|
| |\ \ \ \ \ \
| |_|/ / / /
|/| | | | |
| | | | | | |
virusxp-memory_leakage_fix
|
| | | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
namespace
Fixing some memory issues caused by not correctly freed pointers
|
| | |_|_|_|/
|/| | | |
| | | | |
| | | | | |
free issues
|
| | | | | | |
|
| | |_|/ /
|/| | | |
|
| | |/ /
|/| | |
|
| | | | |
|
| | | | |
|
| |\ \ \ |
|
| | |\ \ \
| | | | |
| | | | | |
Problem converting UCS big endian file
|
| | | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
When having a file with a Big Endian BOM this is not always handled in a correct way when using the generic UCS-2 approach, using the explicit version works well.
(problems see with a gcc (SUSE Linux) 7.4.1 20190905 [gcc-7-branch revision 275407] and glibc-2.26-lp151.18.7.x86_64).
|
| | | | | | |
|
| |/ / / /
| | | |
| | | |
| | | | |
warning.
|
| | | | | |
|
| | | | | |
|
| |/ / / |
|
| | | | |
|
| | | | |
|
| |/ / |
|
| | | |
|
| |\ \ |
|
| | |\ \
| | | |
| | | | |
Problem with horizontal ruler directly after fenced code section
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
When having a fenced code block directly followed by a horizontal ruler like:
```
~~~
B
~~~
---
```
we get the warning:
```
bb.md:5: warning: unexpected command endcode
```
due to the fact that the markdown parser replaces the `~~~` by a `@code` / `endcode` block and then handles the horizontal ruler `---` but this is seen as a level 2 header on the previous part resulting in the markdown code:
```
@page md_bb bb
@subsection autotoc_md0 @code
B
@endcode
```
The problem also occurs when a fenced code block is created with back tics.
By adding a `\n` this problem is fixed.
|
| | |\ \ \
| | | | |
| | | | | |
HHC and directory elements starting with "."
|
| | | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
Based on the question 'Doxygen failed to run html help compiler, hhc.exe error HHC5010 when running from folder that has a parent folder that starts with “.”/ (https://stackoverflow.com/questions/58861908/doxygen-failed-to-run-html-help-compiler-hhc-exe-error-hhc5010-when-running-fro).
In we https://social.msdn.microsoft.com/Forums/en-US/0681145c-223b-498c-b7bf-be83209cbf4e/issue-with-html-workshop-in-a-windows-container?forum=visualstudiogeneral see:
HTML Help 1.x command line compiler hhc.exe cannot compile CHM file to folder whose full path contains folder name starting with dot. If you have that problem, you probably specified output path with folder starting with dot, e.g. "d:\My files.NET\documentation". You can use dots in folder names but not at the beginning.
We first convert the current path to a short name path and set this as current directory, this is only done on Windows other systems are not touched.
|
| |/ / / / |
|
| |\ \ \ \
| | | | |
| | | | | |
issue #7396 Illegal Character in XML output
|
| | | |/ /
| |/| |
| | | |
| | | | |
The usage of, the unusual, `&` in a filename caused troubles as the filenames in the file strings in the location element were not translated to XML.
|
| |\ \ \ \
| | | | |
| | | | | |
Fix line count after multiline close group
|
| | |/ / /
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
Fix for issue #7393
When closing a group on multiple lines, like:
/*! @}
*/
The line count of subsequent lines is wrong (it's one line less than it
should be).
|
| |\ \ \ \
| | | | |
| | | | | |
issue #7290 error: Problem running ghostscript gs -q -g562x56 -r384x384x -sDEVICE=ppmraw -sOutputFile=_form0.pnm -dNOPAUSE -dBATCH -- _form0.ps. Check your installation!
|
| | |/ / /
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
-sDEVICE=ppmraw -sOutputFile=_form0.pnm -dNOPAUSE -dBATCH -- _form0.ps. Check your installation!
@maehr had a talk with Robin Watts and Ken Sharp at IRC and there seem to be basically 3 different problems:
* `-r%dx%d` (the dimension for `r` shouldn't be `-r384x384x`, but `-r384x384`),
* misuse / unnecessary use of `--` and
* since 9.50 the command needs more control access (that might be worked around by either whitelisting the file via `--permit-file-read=_form0.eps` (only works from 9.50 and upwards) or generally accepting any file with `-dNOSAFER` (works since quite some time). The second option is considered to be unsafe if we would process any file, but in this case we process self produced / controlled files. I don't know if doxygen has any threat model that it assumes. ).
> Ken Sharp: Yeah the %dx is wrong, as Robin says its sheer luck that works
the -- isn't needed and is what's causing the first problem
and file control is the new bugbear
The suggestions have been implemented and test / docs works now with old and new version.
|
| | | | | |
|
| | | | | |
|
| | |/ /
|/| | |
|
| |/ / |
|
| |\ \ |
|
| | |\ \
| | | |
| | | | |
Small improvements of TCL output
|
