Mark Hansen [Wed, 21 Oct 2020 10:16:29 +0000 (21:16 +1100)]
Split nslimit and nslimit1 attributes
They're the only attributes that don't already have their own sections,
they complicate parsing and emitting, and on balance I think they're
better explained separately (but next to each other).
This code actually correctly marks the variables that are affected by the
setjmp/longjmp as volatile, but there is still no need for this complexity. A
standard error code return does the trick much simpler. Related to #1801.
Error: RESOURCE_LEAK (CWE-772): [#def39]
graphviz-2.40.1/cmd/lefty/os/unix/io.c:362: open_fn: Returning handle opened by "dup".
graphviz-2.40.1/cmd/lefty/os/unix/io.c:362: leaked_handle: Failing to save or close handle opened by "dup(fd[1])" leaks it.
# 360| panic2 (POS, "ptyopen", "cannot fork");
# 361| case 0:
# 362|-> close (fd[0]), close (0), dup (fd[1]);
# 363| close (1), dup (fd[1]), close (fd[1]);
# 364| execl (shell, shbname, "-c", cmd, NULL);
Error: RESOURCE_LEAK (CWE-772): [#def40]
graphviz-2.40.1/cmd/lefty/os/unix/io.c:363: open_fn: Returning handle opened by "dup".
graphviz-2.40.1/cmd/lefty/os/unix/io.c:363: leaked_handle: Failing to save or close handle opened by "dup(fd[1])" leaks it.
# 361| case 0:
# 362| close (fd[0]), close (0), dup (fd[1]);
# 363|-> close (1), dup (fd[1]), close (fd[1]);
# 364| execl (shell, shbname, "-c", cmd, NULL);
# 365| panic2 (POS, "ptyopen", "child cannot exec: %s\n", cmd);
Error: RESOURCE_LEAK (CWE-772): [#def41]
graphviz-2.40.1/cmd/lefty/os/unix/io.c:429: open_fn: Returning handle opened by "dup".
graphviz-2.40.1/cmd/lefty/os/unix/io.c:429: leaked_handle: Failing to save or close handle opened by "dup(p1[1])" leaks it.
# 427| panic2 (POS, "pipeopen", "child cannot exec: %s\n", cmd2);
# 428| }
# 429|-> close (1), dup (p1[1]), close (p1[1]);
# 430| close (0), dup (p2[0]), close (p2[0]);
# 431| execl (shell, shbname, "-c", cmd, NULL);
Error: RESOURCE_LEAK (CWE-772): [#def42]
graphviz-2.40.1/cmd/lefty/os/unix/io.c:430: open_fn: Returning handle opened by "dup".
graphviz-2.40.1/cmd/lefty/os/unix/io.c:430: leaked_handle: Failing to save or close handle opened by "dup(p2[0])" leaks it.
# 428| }
# 429| close (1), dup (p1[1]), close (p1[1]);
# 430|-> close (0), dup (p2[0]), close (p2[0]);
# 431| execl (shell, shbname, "-c", cmd, NULL);
# 432| panic2 (POS, "pipeopen", "child cannot exec: %s\n", cmd);
In large graphs, the value being printed is frequently zero and the snprintf in
this function shows up as a minor hotspot. Profiling with
tests/regression_tests/large/long_chain this drops the total snprintf calls
within gvprintdouble from 924019 to 858017. This lowers the contributing runtime
of gvprintdouble to overall execution from 28.89% to 28.12%.
use a local instead of reusing global AF in gvrender_polyline
There is a static global, AF, that is reused for a number of gvrender functions,
but none need to retain previous data stored in this array. This hack presumably
was from a time when allocators were much slower. Refactoring this into a local
allocation makes this function thread safe and removes the need to unnecessarily
prolong the lifetime of this allocation, thus decreasing Graphviz memory usage.
This commit introduces a -Wshadow warning about AF, but that will be removed
when we soon remove the static global.
use a local instead of reusing global AF in gvrender_beziercurve
There is a static global, AF, that is reused for a number of gvrender functions,
but none need to retain previous data stored in this array. This hack presumably
was from a time when allocators were much slower. Refactoring this into a local
allocation makes this function thread safe and removes the need to unnecessarily
prolong the lifetime of this allocation, thus decreasing Graphviz memory usage.
This commit introduces a -Wshadow warning about AF, but that will be removed
when we soon remove the static global.
use a local allocation instead of global hack in gvrender_polygon
There is a static global, AF, that is reused for a number of gvrender functions,
but none need to retain previous data stored in this array. This hack presumably
was from a time when allocators were much slower. Refactoring this into a local
allocation makes this function thread safe and removes the need to unnecessarily
prolong the lifetime of this allocation, thus decreasing Graphviz memory usage.
This commit introduces a -Wshadow warning about AF, but that will be removed
when we soon remove the static global.
remove initial stack buffer usage in htmlEntityUTF8
The agxbuf used in this function is eventually disowned and its backing memory
needs to be heap-allocated to live beyond the duration of the function call. So
there is no advantage to initially allocating it on the stack as it needs to be
subsequently moved to the heap.
There are now the following behaviors during configure and compilation:
./configure --enable-man-pdfs ...
PDFs of man pages will be generated using ps2pdf. If ps2pdf is not
installed, pstopdf will be used. If pstopdf is also not installed,
compilation will fail.
./configure --disable-man-pdfs ...
The build will not check for or attempt to generate any PDF versions of man
pages. It is irrelevant whether ps2pdf or pstopdf are installed.
./configure ... (with neither option)
If ps2pdf is found in $PATH, PDFs of man pages are generated using ps2pdf.
If ps2pdf is not found, pstopdf will be looked for and, if found, used to
generate PDFs of man pages. If neither are found, no PDFs of man pages will
be generated and compilation will succeed, omitting these.
projects / graphviz / log